Chapter 13. Successful ATDD

This concludes our journey into acceptance test-driven development, specification by example, or agile acceptance testing. In order to get started with your own business level examples, try identifying acceptance criteria in one of the formats that we worked through. Don’t spend much time on finding the correct format in your case. Adopting a new approach means that you will have to learn new things, play around with some of the concepts, and see what works for you and what does not. Do not let yourself become paralyzed by the many options you can choose. Get started on one particular business flow and start to grow your acceptance tests from that.

I am assuming that you are currently not working with ATDD here, and that you are working on a product that already exists to some degree. You need to retrofit some acceptance tests to the already existing parts. This probably will mean that you have to negotiate with your customer representative how to set the necessary time for this aside. To get the first prototype started, you may want to timebox your efforts. At one client we were charged with creating a prototype for an SWT-based application. I was unfamiliar with the driver for SWT application—we chose SWTBot. We took half a day pairing together to find out how to hook up SWTBot to the SWT application. We had picked a flow through the system that seemed complex enough to have a first prototype, but not impossible to us at that time.

We started with a straightforward approach. We basically had everything in one single big test function when we ran the first test. From that we started to refactor the test code so that it became modular and maintainable in the long run. We took another half day one sprint later to get this approach from JUnit to FitNesse. At that point we had a first step toward our safety-net of acceptance tests.

Where you start with the first set of acceptance tests does not matter much. You should strive for very common business scenarios. At one company we did a risk analysis for the business use cases and based our starting points on the most risky use cases as well as the ones that were most often executed. This ensured that we started on the right foot and could also use the first set of tests and automation code as a baseline for the other use cases.

While becoming more and more familiar and experienced with the approach that you picked, you should also make sure to speak with your business representative about the requirements. Try to find a way to note the examples in the structures you are familiar with. Use the tables to communicate with your business representative and show him or her the end results once you automated these examples.

Remember to include the right persons at the right time in your specification workshops. Refrain from inviting too many people, but also make sure you have the right people at the table. You should also make sure to pick the right moment. If your product owner in Scrum is busy accepting or rejecting the results of your sprint in the final two days, it might not be a good time to discuss the requirements for the next sprint—for your product owner as well as for your team.

When you automated the first few examples, you should also strive to incorporate them into your continuous integration system. Only if your automated tests are executed regularly without thinking about it do they serve you any purpose. For most tools there are plug-ins for commonly used CI systems available. If not, then there is probably a team that already faced a similar situation as you do. Ask on official web or technical sites for support. Maybe the maintainers of the tool also know a way to incorporate the results for your particular CI system.

As your base of automated tests grows and grows, make sure you have a safety net in place for them as well. Over time you may want to change the organization of your tests to reflect your understanding of the domain. In one company we started with the organization based upon use cases. Over time we saw that changes were coming in based upon certain tariff models. We reorganized our tests around different tariff models rather than the business use cases. Whatever the organization you pick first, it will not be a problem to change it later.

Also keep an eye on your automation code base. Make sure to unit test the code you write to automate the tests. This may become tricky in case you use a lot of keywords or scenario tables, because these are usually not unit testable.

Make sure you refactor your code. Regardless of whether you are in a position to grow domain objects out of your automation code, you should strive to encapsulate domain concepts in their own objects. For webpages this might mean coming up with page objects for each webpage, or you might deal with domain objects like money, accounts, users, and receipts. Keeping these concepts in their own classes helps you to make extensions later more easily, and thereby avoiding the test automation maintenance hell that so many teams face.

Over time you may also want to rewrite some of your earlier examples when you see the liabilities of your first steps. Don’t skimp in the effort to change them now before the project grows more complex. The temptation to simply copy and paste this example, change some data, and then check in your results is great. Do not go there. Instead, think about how you might incorporate your new example in a way that it will be easier to come up with additional examples later. You might want to express your tests in a tabular format, or you might seek a new abstraction layer in your examples. Copy and pasting might be easy, but treat it as a symptom to a problem in your code base.

To get started, keep in mind trying out some approach for a limited time, reflecting on your current experiences with it, and adapting. You might speculate a lot about a better approach. Try to get started instead, and solve the problems that you might face when you actually run into them. Track how the tiny changes you actually make contribute to larger improvements over time. I believe this is a recipe for successful approaches—not only considering ATDD, but software development in general.