Tag Archives: Java

Test Driven Development (TDD): Best Practices Using Java Examples

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): Example Walkthrough

medium_5927476303Test-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:

  • Add a test
  • Run all tests and see if the new one fails
  • Write some code
  • Run tests
  • Refactor code
  • Repeat

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

Behavior Driven Development (BDD): Value Through Collaboration (Part 4: Automation)

This post is part of the "Behavior Driven Development (BDD): Value Through Collaboration" series.

Automation

medium_8127187751The 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.

  1. Create library of normalized steps.
  2. Combine steps into composites.
  3. Empower scenarios with examples tables.

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.

Continue reading