Here you can find information and resources about Test-Driven Development.
Test-driven Development is a programming practice that instructs developers to write new code only if an automated test has failed, and to eliminate duplication. The goal of TDD is clean code that works.
__Massol & Husted: JUnit in Action
Test Driven Development is the craft of producing automated tests for production code, and using that process to drive design and programming
For every bit of functionality, you first develop a test that specifies and validates what the code will do.
You then produce exactly as much code as necessary to pass the test. Then you refactor (simplify and clarify) both production code and test code
Source: Brian Nielsen, Arne Skou. Test Driven Development. Retrieved May 30, 2017 from https://goo.gl/lfyX48
The Steps of TDD
Source: Matt Chernosky. (2016, March 14). How to Write Better Unit Tests For Embedded Software With TDD. Retrieved from https://goo.gl/4Y6OtZ
Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle. It can be succinctly described by the following set of rules:
- write a “single” unit test describing an aspect of the program
- run the test, which should fail because the program lacks that feature
- write “just enough” code, the simplest possible, to make the test pass
- run the test again to ensure all the tests pass
- “refactor” the code until it conforms to the simplicity criteria
- repeat, “accumulating” unit tests over time
Adapted from Agile Alliance. TDD Glossary. Retreived May 30, 2017 from https://goo.gl/2EcEZz
The Three Rules Of TDD
- You are not allowed to write any production code unless it is to make a failing unit test pass.
- You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
- You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
You must begin by writing a unit test for the functionality that you intend to write.
But by rule 2, you can’t write very much of that unit test. As soon as the unit test code fails to compile, or fails an assertion, you must stop and write production code.
But by rule 3 you can only write the production code that makes the test compile or pass, and no more.
Source: Robert C. Martin (Uncle Bob). The Three Rules of TDD. Retrived May 30, 2017 from https://goo.gl/6Y2ir5
TDD and ATDD
Test-driven development is related to, but different from acceptance test–driven development (ATDD).
TDD is primarily a developer’s tool to help create well-written unit of code (function, class, or module) that correctly performs a set of operations. ATDD is a communication tool between the customer, developer, and tester to ensure that the requirements are well-defined.
TDD requires test automation. ATDD does not, although automation helps with regression testing. Tests used in TDD can often be derived from ATDD tests, since the code units implement some portion of a requirement. ATDD tests should be readable by the customer. TDD tests do not need to be.
TDD and BDD
Source: Abhay Kumar - LinkedIn
BDD (behavior-driven development) combines practices from TDD and from ATDD. It includes the practice of writing tests first, but focuses on tests which describe behavior, rather than tests which test a unit of implementation. Tools such as Mspec and Specflow provide a syntax which allow non-programmers to define the behaviors which developers can then translate into automated tests.
- Test Driven Development: 15 years later by Petr Jasek, Department of Computer Science, Aalborg University
- TDD from book ‘Scrum and XP from the Trenches’ by Henrik Kniberg
- Back to the Future 2018 – Reloaded by Paul Hardy
- Agile Software Engineering, OPA5, UI5, Test Automation by SAP - June 18, 2016
- Automated Testing by Sarah Lottman, SAP - Septenber 2016
- SAP Test Automation by SAP, July 2012
- ABAP Code Refacotring Techniques by Sukru Ilkel Birakoglu, SAP LABS France - July 6, 2009
- What’s New in Tosca 9.3 by Dr. Gerd Weishaar, Tricentis - 2016
- Conquer SAP Testing with Tosca Test Suites by Wolfgang Platz, Tricentis - 2015
- Automated Testing in SAP (Video) by Tricentis - 2016
- Tosca-SAP Solution Manager Integration (Manual) by Tricentis
- Key Test Design Techniques by Lee Copeland, Software Quality Engineering - June 5, 2014
- Fast Test, Slow Test by Gary Bernhardt - March 11, 2012
- MCE 2014: Jon Reid - Test Driven Development for iOS (and anything) by Jon Reid - February 14, 2014
- The BEST way to do mocking - FunFunFunction #8 by Mattias Johanson - November 19, 2015
See more books at Suggested Reading for Professional Scrum Developer
Click here to submit any questions, comments, or suggestions.