DAY 18
π μ€λ μ½μ λ²μ : Domain-Specific Testing Language ~ 9μ₯ λ
<aside>
π μ±
μμ κΈ°μ΅νκ³ μΆμ λ΄μ©μ μ¨λ³΄μΈμ.
</aside>
- The code within the testing API does have a different set of engineering standards than production code. It must still be simple, succinct, and expressive, but it need not be as efficient as production code. After all, it runs in a test environment, not a production environment, and those two environment have very different needs.
- That is the nature of the dual standard. There are things that you might never do in a production environment that are perfectly fine in a test environment. Usually they involve issues of memory or CPU efficiency. But they never involve issues of cleanliness.
- Fast Tests should be fast. They should run quickly.
- Independent Tests should not depend on each other. One test should not set up the conditions for the next test.
- Repeatable Tests should be repeatable in any environment. You should be able to run the tests in the production environment, in the QA environment, and on your laptop while riding home on the train without a network.
- Self-Validating The tests should have a boolean output. Either they pass or fail. You should not have to read through a log file to tell whether the tests pass.
- Timely The tests need to be written in a timely fashion. Unit tests should be written just before the production code that makes them pass. If you write tests after the production code, then you may find the production code to be hard to test. You may decide that some production code is too hard to test. You may not design the production code to be testable.
- Tests are as important to the health of a project as the production code is. Perhaps they are even more important, because tests preserve and enhance the flexibility, maintainability, and reusability of the the production code. So keep your tests constantly clean.
- If you let the tests rot, then your code will rot too. Keep your tests clean.
<aside>
π€ μ€λ μ½μ μκ°μ? λ μ€λ₯΄λ μκ°μ κ°λ³κ² μ μ΄λ³΄μΈμ
</aside>
In the FIRST rule, the last one βT(Timely)β was the most important message for me.
If you write tests after the production code, then you may find the production code to be hard to test. You may decide that some production code is too hard to test. You may not design the production code to be testable.
I do recall times like this, and Iβm glad that I understand the importance of TDD better now.
<aside>
π κΆκΈν λ΄μ©μ΄ μκ±°λ, μ μ΄ν΄λμ§ μλ λ΄μ©μ΄ μλ€λ©΄ μ μ΄λ³΄μΈμ.
</aside>
- I donβt quite understand/agree that this is an improvement...?