TDD and automated testing

What is? TDD?

TDD Is a core practice and technology in agile development , It's also a design methodology .TDD The principle is before the development of functional code , Write unit test case code first , The test code determines what product code needs to be written .

Why TDD?

image.png

TDD The benefits of

• Reduce the burden on developers Through a clear process , Let's focus on one point at a time , Less burden on thinking .
• Protection network TDD The benefit is to cover full unit tests , It provides a protection net for product code , So that we can easily Meet demand changes or Improve code design . So if your project needs are stable , Do it all at once , If there is no change in the future , Can enjoy TDD The benefits are less .
• Clarify requirements in advance Writing tests first can help us think about requirements , And clarify the details of requirements in advance , Instead of finding ambiguous requirements halfway through the code .
• Quick feedback A lot of people say TDD when , My code volume has increased , So the development efficiency is reduced . however , If there is no unit test , You have to test by hand , You have to spend a lot of time preparing the data , Start the application , Jump interface, etc , Feedback is slow . Accurate said , Quick feedback is a benefit of unit testing .

TDD What matters is not the test code itself , It is the thinking of solving problems , TDD Drive us to be result oriented , Makes us simplify the design , Focus on delivering a stable stack of value streams .

TDD The ultimate goal is Produce clean and usable code

TDD What to do ?

image.png

image.png

TDD The three principles of

• Don't write any functional code before testing
• Write only one test that just failed at a time , As a description of the new function
• Don't write any extra product code , except ⾮ It just makes the failed test pass

meanwhile TDD Also follow the test FIRST principle

• F(Fast)： The test should be able to run quickly
• I(Isolate)： Test cases should be independent , Can't depend on each other
• R(Repeatable)： The test should be repeatable
• S(Self-verifying)： The test will check the output by itself
• T(Timely)： The test should be done in time , And writing code

Background test type definitions

image.png

Test level	A0	A1	A2	A3
Verification scope	Method 、 class	Integration between modules within the service	Single service interface	Multi service multi interface tandem scenario
The upper limit of execution time for a single use case	<=1S	<=3S	<=10S	=1S It is recommended to control 10 Within minutes,
stability	high	high	in	in
Test case and tested object	In the same process / With the machine	In the same process / With the machine	Cross process / Same or different machine	Different machines cross process
Network dependence	Do not rely on	It is recommended to rely on the local network	rely on	rely on
Service dependence	Do not rely on	It is recommended to rely on local test avatars	It is recommended to rely on non substitutes	Rely on non substitutes
Database dependency	Do not rely on	It is recommended to rely on the local database	Access the network database	Access the network database
Execution network	DEV	DEV	IDC	IDC
You need to deploy and start the tested object	Unwanted	Unwanted	need	need
Test type	White box testing	White box testing	Black box testing	Black box testing

Custom test type	Industry test types
A0	unit testing
A1	unit testing
A2	The interface test
A3	e2e test

Test case specification

golang Test case specification

Case presentation

User mobile number password login service , See attachment list for details

See details of specific process : TDD Case actual combat

Automated integration

• Interface test automation can be used directly Yapi Automated testing solutions for go test -coverprofile=c.out ./... go tool cover -html=c.out -o coverage.html
• Unit tests can be executed in advance on the pipeline

common problem

Why do many people do TDD Can't do it ？

• The task will not be split properly TDD Split the task before , Break a big demand into several small ones .
• Can't write tests What are effective unit tests , A lot of people write tests , I don't even know what I'm testing , Or maybe there are no assertions , Output through console , Visual comparison to verify . Good unit tests should conform to simple , Fast , Contains assertions that can be repeated
• Can't write just the right implementation Many people can't focus on the current requirements when writing implementation , Accidentally realized other requirements , It destroys the sense of rhythm . When it comes to implementation, it won't take small steps .
• No refactoring I don't know what is Clean Code, I can't see Smell, Not refactored in time , It's hard to start when you want to refactor . I don't know how to use the right one 「 methods 」 eliminate Smell.
• Backward infrastructure For a particular technology stack , The unit test infrastructure is not built well , As a result, you can't focus on test cases when writing tests . TDD (Test-driven development) It is a kind of automatic test , And give full play to its advantages . If the infrastructure doesn't want to , that TDD It's just the opposite .

Why do you have to write a test first , Is the post test OK ？

That's ok , But after writing the implementation , Write the test now , Use tests to verify the implementation , If the test goes ahead , Use intention driven programming to reduce rework

Test whether the code will become a burden of maintenance ？

Maintenance also follows TDD technological process , First modify the test code to look like the changed requirements , Let the test fail , Then modify the product code to make it pass . So you're not maintaining test cases , It's using test cases .

Why test code should be simple ？

When the test code is simple enough , If a test fails , I have enough confidence to conclude that it must be a product code problem .

When is not suitable for TDD？

If you are doing exploratory technical research （Spike）, No need for long-term maintenance , And the cost of testing infrastructure is very high , Let's try it by hand .

And then there is 「 Legacy systems with poor testability 」 and 「 Use test unfriendly technology stacks 」 The system of , do TDD May not be worth it .

reference

《 Background test type definitions 、 Use case specification 》

《 TDD Five steps of development , Take you to practice Test-Driven Development example 》

《 Test-driven development （TDD） Practice and skills 》

《【 Architect's way - O & M and testing 】 piece 5：TDD（ Test-driven development ） 》

《TDD Implementation outline 》

《 Background automated testing and continuous deployment practice 》

《TDD Case study - Repeat string and bubble sort 》