This chapter summarizes common questions about testing and my answers to them. It may not be the perfect answer, but it may be an answer.
"What's the point of writing a test?"
Some tests may almost meaningless and some are worthwhile. Let's try our best to write tests that have some value!
In addition, tests are more valuable during ongoing maintenance than when they are written. This is because unexpected bugs tend to occur when a feature is modified by someone other than the original implementer, and the test code can cover such bugs to some extent.
"Doesn't it take too long to make?"
It will inevitably take time at first, so we need to estimate the man-hours, including the time to write the test. If you're not used to writing tests, it may take as long as or longer than implementing the features, but it will get faster as you get used to it.
I feel that the total development time for a basic CRUD implementation is about 1.1 to 1.3 times longer when including the test code (of course, but it takes more time when writing code that has many conditional branches or complex DOM manipulations).
Writing tests may reduce costs
It is often the case that a small change in code affects the entire system, but even in this case, if the test passes, you will spend less time manually checking it yourself.
Writing tests can also help you identify patterns of omissions that need to be addressed. Therefore, the time it takes to write test code may not be a big deal, given the reduced likelihood of finding a bug and fixing it later.
"I don't know what kind of test to write."
No wonder you don't know.
In the beginning, try to write as much detailed code as possible, and when you start to feel that "this test is unnecessary", you should reduce it. It might also be a good idea to look at the test code in other projects, such as OSS.
It seems that the standard for how many tests to write is sometimes said to be "until your anxiety turns to boredom".
Once you know how to write tests, you will be able to come up with ideas like, "If I implement the functions this way, it will be easier to write tests", which is a good way to improve the quality of both implementation and testing.
Try writing simple tests first
Let's start by writing simple functional tests, rather than difficult ones. I think the following are simple.
- Validation tests in
model spec. - Tests that a page can be opened and its content has been displayed for a simple GET request in
request spec. - Tests that data has been updated by passing suitable parameters for a simple POST request in
request spec.
They are also necessary to prepare for writing more complex tests, so they are definitely worth doing.
What is TDD? / Should tests be written first?
TDD (Test-Driven Development) is a development method based on the following idea (explained above).
- The idea that "this kind of implementation makes it easier to write tests".
- By writing tests, it can be noticed patterns of omissions that need to be addressed.
If you can proceed with development based on this, it may be possible to call it TDD. This is a matter of interpretation, but TDD is not just about "writing tests before implementing functionality," as is often said.
By writing tests early in the development process, it can move away from the implementation-first, slightly fluffy (non-solid) approach that Agile tends to take to a slightly design-oriented approach that organizes tasks, eliminates omissions, and improves quality and stability. This is one way to interpret the concept. (Does it make sense?)
To put it a little more simply, I would say that tests should not be written as an add-on after the functional implementation is done, but rather the implementation and tests should be considered together to improve each other. Simply writing tests before implementation without this kind of thinking will not make much sense.
Note that testing here refers to white box testing (=RSpec in Rails) done by engineers, not black box testing done by testers. Whether (and how) to do black box testing is another matter.
What does spec mean?
spec is supposed to stand for specification. In other words, the ultimate meaning is "Read the spec to know the system specifications". From this point of view, it is understandable that capybara has aliases that are aware of English grammar.
In reality, however, it is difficult to create such a perfect spec, and the realistic goal may be like "Read the spec to get some clus about the system specifications".
Should coverage be higher?
There may be many opinions from different points of view, but this is my opinion.
- Higher is definitely better, but aiming for 100% does not necessarily lead to system stability.
- In general, it is better to have as many tests as each conditional branch. However, when it comes to complex things like the search function, it is not necessary to cover all patterns.
- In such cases, include some tests for complex parameters, or create random parameters.
- For error handling tests, it is enough to have some tests of what is likely to happen to some extent.
- Required coverage varies by system and function
- If the system or function deals with money, the higher coverage is better.
- If detailed design documents exist, it is desirable to have tests that can guarantee the operation of their contents.
Of course, if there is a testing policy, it is better to follow it. Tests that are not commensurate with the importance of the function or that are extremely different from other members, are not desirable.