BDD, automated acceptance tests and continuous delivery: dealing with scenarios that are 'work-in-progress'
One of the principle rules of Continuous Integration (and Continuous Delivery) is that you should never knowingly commit code that will break the build. When you practice test-driven development this is easy: you write a failing test (or, more precisely, a failing "executable specification"), make it pass, and then refactor as required. You only commit your code once you have refactored and ran all of your unit tests, to ensure that you haven't inadvertently broken anything elsewhere in the code.
But acceptance tests take typically require a lot more code than unit tests, and take a lot longer to implement. If you start with a failing automated acceptance test, you may have a failing test for hours or even days.Add a comment
Data-driven testing is a powerful way of testing a given scenario with different combinations of values. In this article, we look at several ways to do data-driven unit testing in JUnit.Add a comment
This article was writen by Simeon Ross, who works in a large government organization. In it, he describes how he sets up parallel testing in JBehave and Thucydides using Bamboo. Simeon has also put a sample project illustrating the approach on Github
The place that I work for has a data mart project pulling from many sources and it must be accurate. To that end we decided to write a number of JBehave style, data driven JBehave tests utilising Thucydides to ensure its integrity. This was a success until the data grew and the tests were taking too long to complete - some of our stories had massive example tables! While we could speed up the process by tuning the database with indexes we decided that it since it was still in development it could be time wasted if the data/approach was wrong and that wasn't getting away from the issue of the sheer number of tests so we came to the conclusion that the first attack would be running the tests in parallel.Add a comment