A blog on Software Testing, Quality Engineering, Tools, Conferences

Tag: tdd

Developing & Testing – or the other way around?

This week I attended a local meet-up of software testers. Michael Thiele from Saxonia Systems AG gave a talk about his view on testing and developing (original German title: “Testend Entwickeln – Entwickelnd Testen”).

The main message of the talk was that test-driven development on unit test level didn’t work for him and his team. Instead, they are now following the acceptance test-driven approach of development. Starting with the requirements in the specification of the software that is to be developed one derives the actual test cases that will later be used as an acceptance criteria. Michael emphasized that this is already done in code, not in some test case management tool nobody is looking at. Of course, the first description of the acceptance tests is pretty high-level, but it’s of good use to prepare automated checks. One defines the various test cases independent from the technologies that are used to run the tests. Then the implementation of the software or user story is done and unit tests are written directly after that followed by integration tests, if multiple components are involved.

Michael and his team made positive experience with that top-down approach of TDD, especially because developers get used to ask about the acceptance criteria instead of inventing their own. So, it fosters communication between product owner, testers and developers and its a good way to find bugs and gaps in the requirements early.

What is missing in that approach is a good overview of what actually is and isn’t tested. Michael told they tried to extract human-readable test documentation automatically from the test code. I still think that the behavior-driven approach is the better way to achieve the same. With a language like Gherkin you get the test documentation for free and can still benefit from reusing existing test methods, parameterization and so on. It even has good integration into current IDEs.

Summing up, it was a very good talk about a very interesting topic that is relevant for so many software development teams.

Tests should be easy to read

Yesterday, I read an article about how to unleash the power of Test-driven Development*. I liked most of it so much that I would like to share and discuss some of its main thoughts. What I liked most about it were the concepts of how tests can be written in a way that is easy to read and understand. To assure long-term quality of tests it’s important to comply with some conventions regarding partitioning, naming and structure. I totally agree with the authors that the Cucumber project with the Gherkin language and all its tools is a good reference for easy-to-understand test design. Especially the natural language of the test cases facilitates comprehension for the readers who can then dive into step definitions and the actual test code. Even if you’re not willing to use Cucumber / Gherkin in your test solution you can benefit from its concepts. If you make use of its three phases Given / When / Then in existing test cases, even unit tests get a better structure and readability. Additionally, the authors point out the following requirements for clarity in tests:

  1. Tests should be short. Each section should only contain few lines of test code.
  2. Each test should only check one scenario of a feature.
  3. Tests should be concise, only showing the relevant aspects and hiding insignificant details.

Especially to reach the goal of the third point the authors recommend to use builder classes and helper methods from a small test DSL. All these recommendations are finally used in the following example of a readable test case:

public class OrderTest extends TestBase {
    public void test_order_single_product_in_stock() {
        // Given:
        User user = database().persist(a($User()));
        Product product = database().persist(a($Product));
        // When:
        // Then:

Having good readability like in this example results in faster understanding of what is actually tested and better maintainability. More tests should be like this one!

* original article: “Interne Prüfung. Wie Test-driven Development seine Stärken entfaltet.” by Michael Karneim and Oliver Kraeft in magazine “iX”, Vol. 9 / 2016, pages 84-88.

© 2024 BlueTopTesting

Theme by Anders NorenUp ↑