Automatic Test 2019-07-25
- 2. Drawbacks ● slow startup configuration ● it must be maintained ● hard to apply in legacy code ● hard to choose type of test ● the cost of change mindset ● request many refactoring ● you cannot test everything Federico Guerinoni - guerinoni@micro-systems.it
- 3. ● avoid regression of business/application logic ● verify single piece of code (algorithm, class…) ● make it simple to write structured and encapsulated code ● clarify customer requirements ● reduce development time of new features ● reduce maintenance old code ● because this is automatic ● safer refactoring Why? Federico Guerinoni - guerinoni@micro-systems.it
- 4. Federico Guerinoni - guerinoni@micro-systems.it
- 5. F.I.R.S.T. ● Fast: should be fast. They should run quickly ● Independent: should not depend on each other ● Repeatable: should be repeatable in every environment (QA, production, laptop...) ● Self-validating: should have a boolean output. Should either pass or fail ● Timely: should be written before production code Federico Guerinoni - guerinoni@micro-systems.it
- 6. The Three rules of TDD 1. write production code only to make a failing unit test pass. 2. write only enough of a unit test to fail. 3. write only enough production code to make the failing unit test pass. Federico Guerinoni - guerinoni@micro-systems.it
- 7. TDD vs BDD (DDD and ATDD) ● focus on single unit ● probably change tests when refactor ● no GUI support ● focus on output of function ● focus on requirements ● probably change tests when customer request changes ● GUI support ● check ● focus on integration between class Federico Guerinoni - guerinoni@micro-systems.it
- 8. Mock vs Stub vs Fake Fakes: is an object that has some sort of actual working mechanism inside that returns a predictable result, but doesn’t implement the actual production logic. Stubs: is an object that will return a specific result based on a specific set of input. If I tell my stub to return “John Doe” whenever I ask it for the person with ID number 42, than that’s what it will do. Mocks: is a much more sophisticated version of a Stub. It will still return values like a stub, but it can also be programmed with expectations in terms of how many times each method should be called, in which order and with what data. Mocks provide features that ensure that our code under test is using it’s dependencies in a very specific way. Federico Guerinoni - guerinoni@micro-systems.it
- 9. Qt Test ● very integrated with QtCreator ● support of Qt class ● support widgets test ● support qml test ● low mock support ● create many binaries ● benchmark integration ● difficult to integrate with CI/CD Federico Guerinoni - guerinoni@micro-systems.it
- 10. Example Federico Guerinoni - guerinoni@micro-systems.it
- 11. Google Test ● integration in many IDE ● no gui support ● build in one binary ● support mocking ● easy to integrate in CI/CD Federico Guerinoni - guerinoni@micro-systems.it
- 12. Example Federico Guerinoni - guerinoni@micro-systems.it
- 13. Squish ● BDD oriented ● not free ● recording and playback ● IDE to create and verify test ● support for GUI ● integrated with Qt ● cross-platform Federico Guerinoni - guerinoni@micro-systems.it
- 14. Cucumber ● tool that support BDD ● request gherkin language ● agile oriented ● support many programming language ● report of test can be used with customers Federico Guerinoni - guerinoni@micro-systems.it
- 15. Example Federico Guerinoni - guerinoni@micro-systems.it
- 16. Continuous Integration Federico Guerinoni - guerinoni@micro-systems.it
- 17. Thanks Federico Guerinoni - guerinoni@micro-systems.it