Refactoring Unit Tests

Anyone who wants to change existing code must also understand the associated tests. This brief presentation shows how comprehensible JUnit tests can look like: Existing unit tests are refactored using descriptive names, BDD structures and speaking assertions. JUnit 4, AssertJ and Awaitility are used.

Transcript

1. .consulting .solutions .partnership Refactoring Unit Tests Alexander Schwartz, Principal IT Consultant JUG Darmstadt / 7. December 2017
2. Demo © msg | Dezember 2017 | Refactoring Unit Tests | Alexander Schwartz 2
3. Summary © msg | Dezember 2017 | Refactoring Unit Tests | Alexander Schwartz 3 Ideas: • Consider tests to check for features, not (only) classes • Introduce test methods with “should” to describe expected behavior • Add a “when” to describe conditions for a test • Use underscores to make the methods readable. Use capital letters and even Umlauts! • Break down the test in given/when/then • Try out AssertJ matchers for readability and fluent API • Use Awaitility for fast execution and avoid fixed sleep in execution Benefits: • When a test fails you can read up about the requirements in the code • Tests can be linked to business requirements and/or acceptance criteria • Test scope (what to test) and test steps (how to test) can be discussed with business owners
4. Links © msg | Dezember 2017 | Refactoring Unit Tests | Alexander Schwartz 4 JUnit http://junit.org AssertJ http://joel-costigliola.github.io/assertj/ Awaitility https://github.com/awaitility/awaitility Samples of today’s demo https://github.com/ahus1/bdd-examples @ahus1de Other libraries (not shown today) JGiven http://jgiven.org/ JUnit Dataprovider https://github.com/TNG/junit-dataprovider Mockito http://site.mockito.org/
5. .consulting .solutions .partnership Alexander Schwartz Principal IT Consultant +49 171 5625767 alexander.schwartz@msg-systems.com @ahus1de msg systems ag (Headquarters) Robert-Buerkle-Str. 1, 85737 Ismaning Germany www.msg-systems.com