개발자 99% 커뮤니티에서 수다 떨어요!
오늘 TIL 3줄 요약
Unit tests and production code are both important.
Tests should have one concept per test.
F.I.R.S.T.
TIL (Today I Learned) 날짜
2022.03.06
오늘 읽은 범위
Unit Tests
책에서 기억하고 싶은 내용을 써보세요.
We are talking about Test Driven Development.
For the vast majority of us, unit tests were short bits of throw-away code that we wrote to make sure our programs "work".
First Law. You may not write production code until you have written a failing unit test.
Second Law. You may not write more of a unit test than is sufficient to fail, and not compiling is failing.
Third Law. You may not write more production code than is sufficient to pass the currently failing test.
What this team did not realize was that having dirty tests is equivalent to, if not worse than, having no tests. The problem is that tests must change as the production code evolves. The dirtier the tests, the harder they are to change.
The moral of the story is simple: Test code is just as important as production code. It is not a second-class citizen. It requires thought, design, and care. It must be kept as clean as production code.
If you don't keep your tests clean, you will lose them. And without them, you lose the very thing that keeps your production code flexible.
It is unit tests that keep our code flexible, maintainable, and reusable.
The dirtier your tests, the dirtier your code becomes.
Eventually you lose the tests, and your code rots.
What makes a clean test? Three things. Readability, readability, and readability.
What makes tests readable? The same thing that makes all code readable: clarity, simplicity, and density of expression.
Anyone who reads tests should be able to work out what they do very quickly, without being misled or overwhelmed by details.
That is the nature of 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.
I think the single assert rule is a good guideline.
But I am not afraid to put more than one assert in a test.
I think the best thing we can say is that the number of asserts in a test ought to be minimized.
Perhaps a better rule is that we want to test a single concept in each test function.
So probably the best rule is that you should minimize the number of asserts per concept and test just one concept per test function.
Clean tests follow five other rules that form the above acronym:
Fast. Tests should be fast. They should run quickly.
Independent. Tests should not depend on each other.
Repeatable. Tests should be repeatable in any environments.
Self-Validating. Tests should have a boolean output.
Timely. Tests need to be written in a timely fashion.
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 production code.
So keep your tests constantly clean.
오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요
Whenever I'm writing some code, for example, to record a data for my experiment, I'm always starting with a file called 'test'. I guess what I have been doing is right pathway, but I have not paid good attention to make it nice and clean. Maybe, I should start with naming those test files differently.
궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
What is the assert?
What is the TDD (Test Driven Development)?
오늘 읽은 다른사람의 TIL
I have not read others' TIL.