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...?