The back of the leaflet.
Presentation material of the first Mr. Terashima ↓ Spring program model and working specifications-test edition-
--In the test, write in advance condition (give), operation (when), and result (then). --Spock, a test library written in Groovy, is convenient. --Automatic testing is positioned as a working specification.
Case:
Meeting coverage is not the purpose of testing! The specification level story is left as a comment, and it is not necessary to specify (hide) the non-essential operation method. The part that is not related to the specifications is also transferred from the product code (Is the Service class a story that concentrates on business processing?).
With DI container, it became possible to solve the part other than the test viewpoint with stub and mock.
--Release from the binding of the framework parent class --Dependency injection resolves dependencies
Mock will be introduced more and more in the part that is not the test viewpoint.
The part replaced with a mock is tested separately, and the hierarchy is lowered to a level that cannot be finally replaced with a mock. Obviously, it's NG to mock a test-oriented method!
It can be applied from E2E test / scenario test to test of one method. It is necessary to pay attention to the particle size of the specifications. It is important to test the usage of the test target = test the specifications.
As a caveat when writing granularity, the expression XX flag is programmatic and far from business, so use the term used in business.
I actually wrote a manual test in-house with give-when-then.
--Run tests, get evidence, and finally review. From this flow, I was able to review what kind of test to do in advance, so rework is reduced. -Psychological safety because the programmer understands and proceeds with the test. ――There is no difference in the quality of the deliverables just by changing the test method. --Increased document creation costs.
Future outlook How to test a huge amount of product code. Also, in order to guarantee quality, refactoring is also expensive.
――I want to centrally manage scattered test specifications. ――I would like to create an example using Spock and E2E automated testing. ――Aside from approaches such as BDD and ATDD, it is a major premise that the code is readable.
↓ Presentation material of the second person, Mr. Otomori Proposals and tools for hypothesis verification development in the API era-API edition-
Traditional development: In the early stages, "There is a rework if you verify it at the stage of omission of examination or implementation. Specifications and" code version control is required.
Case 1: Designed for half a year, prototype, and later developed for one year. Needs collaboration with multiple vendors. Each vendor has different properties (whether there is a design document, whether the source can be read, etc.). It is important to know at what level the person who uses the API and the person who creates it can communicate. Design document, environment, source (environment: deployed and API can be hit).
When the vendor changes the return value, how to cooperate is important. There may be a discrepancy between the design document provided by the vendor and the actual source.
Case 2: There is a possibility that recognition discrepancy may occur because it cannot be explained face-to-face.
Therefore, hypothesis verification development
-Is your request correct? -Is the specification correct? -Is the deliverable correct?
Hypothesis, input / output confirmation, provisional implementation, and main development. Tool to verify each ↓.
Swagger Swagger can be used to resolve the discrepancy in particle size. The creator can hit the API just by writing yml with Swagger editor. The user does not have to look at the source. However, since it is not linked with the source, if there is a source change, yml also needs to be modified.
SpringFox Specifications can be generated from the source code. The recognition discrepancy is reduced because the specifications can be shown to those who use the API. Whether or not you can actually hit it is another matter.
Spring REST Docs When the test is executed, the document of the successful test is output to AsciiDoc. Since it can be converted to html or pdf with Gradle, there is no gap between the document and the source. The document of the failed test is not output, so it is not a substitute for the design document.
After all, the balance between speed and particle size is important.
Recommended Posts