Questions about test-driven development

TDD is not a test technique, but a development technique.
When implementing small parts such as classes, write down a simple test code in advance to invoke the API (such as the public method) and then actually implement the class.

This allows you to design and implement the parts you really want.Of course, it helps you find simple bugs, but it doesn't cover test cases.

In doing so, test codes often use simple assertions (often simple verification checks such as equal, large, or null) to determine what the return value of the invoked method is.Testing is not necessary because testing does not have logic.

On the other hand, if you write logic to the test side, something is not going well.

TDD has many explanations on the web, but I personally thought The RSpec Book (David Chelimsky Dave Astels Zach Dennis Co., Ltd.)|Sho Young's book was written in TDD and BDD (behavior development).

TDD's methodology makes it difficult for people to "test" themselves.This is a big benefit of TDD.Instead of writing tests that are complex enough to require testing, TDD's methodology is to stack up concise, unmistakable test codes.

TDD generally uses some kind of test framework.You can isolate pre-preparation and clean-up from test codes, simplify complex behavior using mocks, and write test conditions using specialized grammar to keep the test code concise.A simple code leaves little room for bugs.

Assuming testing in the test framework, the implementation code is also required to be a testable implementation.

• Reduce dependence on internal states
• Predictable behavior
• Determinable Output

and so on.

So far, the theory of the test itself is not directly related to TDD.In addition, there are two benefits to protecting TDD's "test first."One is that the above testable code can be guaranteed by being forced to do so.

The other is the pre-culture of test conditions.Writing test conditions in advance eliminates the error of writing test conditions to match the implementation code.Also, you have to make sure that the test fails immediately after you write the test, so you can eliminate bugs such as incorrect test targets and incorrect decision criteria.

If you write the test later, you will not be able to determine if you are succeeding in order to succeed, or if you are succeeding even though you should not.

In addition, TDD requires that Red→ Green→ Refactoring be turned in as small a step as possible.This will keep the test and implementation codes clean all the time.