Short introduction about test-driven development theory and a walk of tools that help us to do better-tested code.

1. AUTOMATIC
TEST

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