1. What is Test Driven Development (TDD)?
TDD is a way of developing software from Test case, Test case will be written first to determine the basic requirements required. In other words, Test case for each function will be created to test before code, if Test case fails, development will check and update the code to pass the Test case created earlier. clear, simple and error-free.
TDD starts out by designing and writing tests for every little functionality of the application. According to the TDD approach, the first test is written to validate what the code will do, do it right or not.
In the normal software testing process, we write code and then write tests. The test may fail to test after the request has been coded. To pass this test, the developer must refactor the code again.
The simple concept of TDD is to write and properly run faulty tests before writing new code. This avoids code duplication because we only write short code to pass a small request to test.
TDD is an automated testing and development process before actually embarking on application development (before coding). Because of that, TDD is sometimes also known as Test First Development
2. How to apply TDD?
Here are the steps to practice TDD:
- Create test
- Run the test and check to see if there is an error
- Write code
- Run test and refactor code (of course, refactor to pass test)
- Repeat the above steps
A TDD loop can be identified as follows:
- Write test
- Run the test
- Fix the code to run the test properly
- Repeat the above 3 steps
Some things to clarify about TDD:
- TDD doesn’t focus on testing or on design
- TDD doesn’t mean “write test scripts and then build a system so that it passes these test scripts”
- TDD doesn’t mean testing more
4. TDD With Traditional Testing
The TDD-style approach is a special technique. It ensures that your source code is always thoroughly checked at confirmation level (confirm input / output).
With traditional testing, successful testing means finding errors. It is like TDD. Having errors means everything is still in progress, because you know you need to fix the problem.
TDD ensures that the system meets the requirements, you can have complete confidence in the system.
TDD focuses on production to ensure testing is correct. Traditional testing focuses on test case design.
TDD, coverage is 100%. Every line of code is tested, unlike traditional testing.
In the Agile model, you should “test purposefully”. You should know why you are testing and what level it is
5. What is Acceptance TDD and Developer TDD?
There are 2 levels of TDD:
Acceptance TDD (ATDD): with ATDD you write an acceptance test. This test either meets spec requirements or satisfies system behavior. Then write enough code to fulfill this test. Acceptance testing focuses on the overall behavior of the system. ATDD is also known as Behavioral Driven Development (BDD).
Developer TDD: you write test (unit test …) and write enough code to pass that test. Unit tests focus on each of the small functions of the system. Developer TDD is called TDD.
TDD is expanding through Agile Model-driven Development (AMDD)
TDD is good at validation and detailed specification. It fails to come across through larger issues like the overall design, system usage or the user interface. AMDD solves the Agile scaling problems that TDD does not address.
Hence AMDD is used for larger problems.
Compare TDD with AMDD
- TDD shortens programming time
- TDD is for spec detail
- TDD ensures code quality
- TDD is for programmers
- TDD is limited to software only
- AMDD shortens modeling time
- AMDD applies to large scale problems
- AMDD ensures quality communication between developers and stakeholders
- AMDD is for business analysts, stakeholders, and data professionals
- AMDD has a wider range, including stakeholders, towards a common sense
6. Common mistakes when applying TDD
- Regardless of failed tests
- Forget about the optimal operation after writing code for the test pass
- Optimizing code while writing code for test pass => shouldn’t be like that
- Naming confusing and obscure tests
- Don’t start from the simplest tests and don’t follow baby steps.
- Only run each test that is currently failing
- Writing a test with the script is too complicated
7. TDD Reference Examples
- Part I – Test-Driven Development by example – Kent Beck.
- Part III – Test-Driven Development: A practical guide – David Astels.
8. Support tools
cppUnit, csUnit (.Net), CUnit, DUnit (Delphi), DBFit, DBUnit, HTMLUnit, HTTPUnit, JMock, JUnit, NDbUnit, NUnit, OUnit, PHPUnit, PyUnit (Python), SimpleTest, TestNG, Test :: Unit (Ruby ), VBUnit, XTUnit.
This article just hopes to help you understand the basics of TDD. You need to learn more to be able to understand more deeply, practice well about TDD and apply it effectively in your work. You can refer to the Website at the reference link below to learn and practice the best way!