A programming kata is an exercise which helps a programmer hone his skills through practice and repetition.
This article is part of the series “Scala Tutorial Through Katas”. Articles are divided into easy, medium and hard. Beginners should start with easy ones and move towards more complicated once they feel more comfortable programming in Scala.
For the complete list of Scala katas and solutions please visit the index page
Continue reading
A programming kata is an exercise which helps a programmer hone his skills through practice and repetition.
This article is part of the series “Scala Tutorial Through Katas”. Articles are divided into easy, medium and hard. Beginners should start with easy ones and move towards more complicated once they feel more comfortable programming in Scala.
For the complete list of Scala katas and solutions please visit the index page
Continue reading
DISCLAIMER: This is not a tutorial on how to learn Python, in fact, I have never used Python before so don’t take me as example. What I want to share with you is how to learn a new language, strenghen the TDD principles and practice a Kata in an easy way.
Last week I attended the Global day of Code retreat in Barcelona. It was a wonderful experience that generated me a lot of energy to code again (I became a manager some time ago and I don’t code as often as I’d like to). That day we used the Conway’s Game of Life which I recommend to practice the TDD approach.
After investigating about several other katas I stumbled upon the Cyber dojo online tool. Basically this is a web page in which you can practice any kata and choose among more than 20 languages you want to learn without the need to do any setup at all. In other words, if you want to grasp the basics for a new language, this is the perfect place.
Also, one of the nice features from Cyber dojo is that after you’re done with all the coding you wanted to do, you can download all your changes into a zipped Git file and then you have the repository with all the changes that you worked on.
In the previous article Test Driven Development (TDD): Example Walkthrough an example of TDD was given. It went from writing first test and its implementation to having a set of requirements fully tested and developed. Now it’s time to learn what the best TDD practices are. This article will be built on examples from the previous one.
Best practices are solutions to a set of problems under certain situations. Not following them would make us “reinvent the wheel” and struggle with the same problems already solved by others. On the other hand, best practices should not be followed blindly. They should be tried out. With an informed decision at hand, they can be adopted as they are, modified to serve better specific situation or fully discarded.
Some of the best practices described here are inherited from other sets of practices and used when doing TDD. For example, most (if not all) unit testing practices should be used when doing TDD.
Continue reading
Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards.
The following sequence of steps is generally followed:
There’s a plenty of articles written on TDD and Wikipedia is always a good start. This article will focus on the actual test and implementation using variation of one of the Roy Osherove Katas. Do not click the link until you’re finished with this article. This excercise is best done when not all requirements are known in advance.
Below you will find the test code related to each requirement and afterwards the actual implementation. Try to read only one requirement, write the tests and the implementation yourself and compare it with the results from this article. Remember that there are many different ways to write tests and implementation. This article is only one out of many possible solutions.
Let’s start!
Continue reading
If you are still working in a waterfall methodology, you should know that the world is moving towards new methodologies… some famous concepts would be Agile, XP or Scrum and surely those words will sound familiar to you especially during the recent years.
Especially in the case of scrum, the first scrum team in which Jeff Sutherland participated took place in 1993, literally 20 years ago, and now it’s mature enough to be taken by big companies.
This post is part of the “Behavior Driven Development (BDD): Value Through Collaboration” series.
The first 3 posts explored the process to define project requirements as behaviors. Once you have mastered writing BDD stories you are ready to start the journey towards the automation of scenarios.
Execution of BDD scenarios can be accomplished using many different frameworks. Some of them are JBehave (Java), Cucumber (Ruby), RSpec (Ruby), SpecFlow (.Net), and Jasmine (JavaScript). This post will use examples from JBehave. With slight modifications, they can be applied to any other framework. The above-mentioned frameworks provide installation instructions and documentation on how to write code that supports BDD. This article focuses mostly on the best practice and ways to avoid some of the common pitfalls. For detailed installation instructions and documentation, please consult the website of the selected framework.
Decision on which framework to choose should be based on which technology your team is most comfortable with, as well as the support it provides for the implementation of the phases described below. Next post in this series will provide comparison of different BDD frameworks.
Successful implementation of the BDD automation should be done in three phases.
You should start with the first phase. As soon as enough steps have been created to support the first scenario, you can start with execution of the other two phases. From there on, work on all three phases should be done in parallel.
This post is part of the “Behavior Driven Development (BDD): Value Through Collaboration” series.
The goal of software projects is to deliver value to stakeholders. Even though that might sound an obvious statement, it can be easily forgotten in traditional Waterfall projects. The very nature of the Waterfall process fosters the creation of different departments whose job is to receive work from the previous stage, produce something, and pass it on.
A simplified Waterfall model would be:
Each of these phases tends to have separate teams and departments. BAs work with requirements, architects write design documents, developers code, integration engineers integrate, testers test, and someone installs the software. Each of these departments is waiting for others to produce something, to start working on their artifacts and, once finished, to pass it on to someone else. The value for the stakeholders is, in many cases, unknown or forgotten. Most people involved in such projects are concerned about “doing their part” and throw it “over the wall” to those coming next. Moreover, artifacts produced by one team are often not used or understood by another.
To programmers, benefits of source control are obvious. Revision history, revert and recovery, team work, build and continuous integration tools integration, and so on and so forth. No one is questioning usage of source countrol any more. It all boils down to a simple rule: if it is not in source control, it does not exist. Build and continuous integration tools expect it to be in source control. If it is not there, it will not be built. If it was not built, it will not be deployed. If it was not deployed, it will not be tested. If it was not tested, it will not be put to production.
Technology Conversations 