This is a creation in Article, where the information may have evolved or changed.
Part IV: Go microservices-testing and simulation using Goconvey
How to deal with microservices testing? Do you need to consider any unique challenges when establishing a test strategy for this particular area? In the fourth part, we will look at these topics.
- Test the subject of the microservices in the context of the cell.
- Write Goconvey of BDD-style unit tests.
- Introduces simulation technology.
Since this section does not change the core service in any way, it does not require benchmarking at this time.
Introduction to micro-service testing
First, we should remember the principle of testing pyramids in our minds.
Unit tests should form the bulk of the test, as integration testing, E2E testing, system testing and acceptance test development and maintenance costs are increasing.
Second, microservices must have some unique testing challenges, and some of them are like the sound principles used to implement a software architecture for real-world Testing Services (principles). In other words, I think the details of microservices go beyond the scope of traditional unit tests, which is what this chapter addresses.
Anyway, I would like to highlight a few points:
- Unit testing as usual: Your business logic, converters, validators, and so on are nothing magical, because they all run in the context of microservices.
- Integration components, such as communicating with other services, sending messages, accessing databases, and so on, should consider the use of dependency injection and the form of a mock-up design.
- Many microservices details: Access configuration, communication with other services, resiliency testing, etc. if you don't spend a lot of time writing a small, detailed value simulation, it's hard to do unit testing. Save such tests to the class integration test so that the dependent services are actually used as Docker containers in the test code. It will provide greater value, or it may be easier to run up and running.
Source
Ready to be perfected
Other types of tests
Summarize
Key terminology
- Unit tests: Unit testing. is to test the code's own behavior.
- Integration test: Integration testing. Also called assembly Test or joint test. On the basis of unit testing, all modules are assembled into subsystems or systems according to the design requirements, such as the structure diagram, for integration testing.
- E2E test: End to end testing. is a test that simulates the behavior of a user.
- Systems Test: System testing. Is the test of the whole system, the hardware, software, operators as a whole, to check if it does not conform to the system manual. This test can uncover errors in system analysis and design. If the safety test is to test whether the security measures are perfect, can ensure that the system is not illegal intrusion. For example, a stress test is a test system that works properly in the normal amount of data and the amount of overload, such as simultaneous access to multiple users.
- Acceptance Test: Acceptance testing. The acceptance test is the last Test action before the software is deployed. Software testing activities performed prior to product release after the SOFTWARE product has completed unit, integration, and system testing. It is the final stage of a technical test, also known as a delivery test. The purpose of the acceptance test is to ensure that the software is ready and that it can be used by end users to perform the established functions and tasks of the software.
- Test-Driven Development: TDD (Test driven development).
- Behavior-Driven Development: BDD (Behavior Driven development).
Reference links
- Test pyramids
- Goconvey
- English original
- Micro-Service Series entrance
- Next section
