Efficient Testing Building a Pyramid April 2021 Toine

Efficient Testing Building a Pyramid April 2021 Toine Siebelink (Ericsson) toine. siebelink@est. tech

The Test Pyramid • Balance Cost & Confidence • Appropriate Feedback speed • Stability! Recommended reading: Martin Fowler Practical-test-pyramid.

ü Regression testing, prevent breaking code accidently ü Describe code behavior - Explore edge-cases Unit Test Principles ü Fast feedback (seconds) ü Can help during development (BDD, TDD) ü Strive to cover (almost) all code branches (instructions) (CPS projects > 97%)

Unit Test Scenarios L 1. A L 1. B L 1. C A-Test / Spec B-Test / Spec L 2. E L 2. D D-Test / Spec L 2. F E-Test / Spec L 3. G L 3. H L 3. I G-Test / Spec H-Test / Spec • L 1. A Class with simple methods (e. g. delegating to L 2. D) can be unit tested with Mocks or real dependency. One simple C-Test / negative scenario. NOT alternative paths Spec • positive L 3. G andand L 3. H represent classes. Do that usetest CRUD operations on possible in L 2. F (definitely notcan whenused usingtomocks!) a Database. Test-Containers include a real • L 2. D & L 2. E Are both basic classesbethat use the complex class database prevent mocking. L 2. F. Theyand could all be complex tested using separate unit test. It might • L 1. B Could be a simple data holder. Can have its own testthe or if Mocking wouldtoalso a lot ofcode uncertainty be convenient testleave all possible paths inregarding L 2. F through it is used by L 1. A it could in aa test for L 1. A too. exact schema which couldbebeused/tested mitigate with DB container just L 2. D or L 2. E. F-Test / image using the same schema setup code from the production Be careful of duplicating tests for scenarios in L 2. F in many Spec • L 1. C method with many paths. Should have good unit code. Class e. g. For using Liquibase. ‘clients’. other clients a single positive & negative test covering all paths might suffice using mock or real dependencies. • L 3. I represent a class in the persistence layer that does not directly depends on a DB e. g. data transformations. This I-Test / should preferably be tested using a unit test (with mocks) to Spec prevent slightly more complex and slower DB Container tests. Spock Data Driven Testing is ideal for this

Continuous System Integration Test (CSIT) Features Test scope L 1. A L 1. B L 1. C L 2. E L 2. D L 2. F L 3. G L 3. H L 3. I C S I T T e s t s • Purpose: verify correct integration of the modules of one component (e. g. CPS) • Ensure modules (sub-components) can talk to each other • Might not use & test production-deployment configuration helm charts (oom) • Controlled environment e. g. through use of mocked external dependencies • Could be achieved by 1 single positive test case • Test(s) need to involve all sub-components • More test could be added for illustrative purposes (beware of maintenance costs)

Continuous System Integration Test (CSIT) E 2 E (Use Case) Test • Purpose: verify deployment of several scope Client Component A • As close to actual customer deployment using oom charts etc. Component B scope Dependency Component C components for a ‘Use Case’ E 2 E • ‘end’ depends on your perspective: • Team working on Component A is responsible for E 2 E test starting at Component A T e s t s • Could be achieved by 1 single positive test case • Test(s) need to involve all sub-components • More test could be added for illustrative purposes (beware of maintenance costs)

• Groovy & Spock • More readable (natural language) test • Access to private class method & data without manipulating production code • Speed up testing alternative paths using tables etc. • DDF Presentation Useful Technologies • Sprint Boot Web MVC Test (@Web. MVCTest & Mock. Mvc) • Test REST 2 Java interface • Test Containers (@Testcontainers) • (Semi) integration test with quick feedback • No quiet unit test speed but almost! • Easy to use with (but not limited to) Spock, see https: //www. testcontainers. org/test_framework_inte gration/spock/

Example 1: Data Driven Spock/Groovy

Example 2: SQL Test Container

• Do not add test ‘later’ • Configure jacoco to execute (coverage) ‘check’ goal as apart of mvn install • Do not add unnecessary data/setup for any test • Strive for minimum maintenance • Simple plain text examples Dont’s • Do not abuse ‘data tables’ • Separate small groups (even single) variable into separate tests • Do not duplicate Tests • Test alternative paths in appropriate place • Do not mix j. Unit & Spock in package (reports will be overridden. Stats will only see ‘last report’) • Migrate one package at the time if needed

• https: //www. baeldung. com/groovy-spock • http: //spockframework. org/spock/docs • https: //github. com/spockframework/spock-example • http: //groovy-lang. org/documentation. html • http: //spockframework. org/spock/docs/1. 3/data_driven_testing. html Resources • https: //www. jetbrains. com/help/idea/getting-started-withgroovy. html#create_groovy_project • https: //gerrit. onap. org/r/admin/repos/cps • https: //wiki. onap. org/pages/viewpage. action? page. Id=92998161 (CPS Team Spock/Groovy Conventions)