You’ve just pushed the final commit for this new feature to the source control system. Only a few more hours for the CI pipeline to run all the tests and the system is ready to deploy. After the build finished, you notice that a couple of tests have failed. That’s strange, they don’t seem to be related to this new feature. Let’s just start the CI build again. Urgh, that means more time waiting for it to finish. So you wait, and wait, … and then, after a long while, you get notified of a “green” build. Then you suddenly realise that you’ve forgot to add some UI tests for the new feature. D’oh, this is going to keep you busy for the rest of the day. It takes forever to write a new test like that.
These are a small selection of the joys software developer have with UI tests and other kinds of integrated end-to-end tests. Why do we keep doing this to ourselves? In this talk, we’re going to address the underlying issues caused by integrated end-to-end tests and discuss an alternative approach that results in faster feedback, a lower investment cost and above all, a feeling of trust and confidence in your developer tests.
A simple practice like Test-Driven Development provides us with a lot techniques and patterns. How can we find a good balance in all these approaches?
The world of automated tests can be quite overwhelming. Tests exist in a wide variety of flavours, like unit tests, integration tests, API tests, database tests, acceptance tests, UI tests, performance tests, regression tests, smoke tests, etc. … All of these have their usefulness for the specific purpose that they are serving. However, they can all be broken down into two broad categories: Solitary and Sociable tests. These can be seen as the equivalent of tests that either run very fast, and tests that have a wider variety of slowness.
When zooming in further on Solitary Tests specifically, we find that there are generally two different types of verification: state verification and behaviour verification. How and, most importantly, when should we apply these types of verification? There’s a lot to learn about a seemingly simple practice as Test-Driven Development. In this workshop we’re going to discover why it’s important to find a balance in TDD and how to accomplish this.
This workshop is for developers who already have experience writing automated tests and want to improve upon their existing skills in writing unit and integration tests. By the end of this workshop, participants will have gained the knowledge necessary to build loosely coupled, highly maintainable and robust tests that are trustworthy and improve the overall code quality of your software applications.
Part 1 - The Automated Testing Landscape
Part 2 - The Anatomy of Automated Tests
Part 3 - State Verification
Part 4 - Behaviour Verification*
Jan is a professional software developer since Y2K. A blogger since Y2K+5. Author of Writing Maintainable Unit Tests. Provider of training and coaching in XP practices. Curator of the Awesome Talks list. He is thinking and learning about all kinds of technologies since forever.
Software development is one of his great passions in life. His goal as a software craftsman is to provide simple and qualitative solutions to complex business problems. In order to accomplish this, he's continuously deepening his existing skills and expertise while learning new skills and broadening his horizons. Sharing his knowledge and experiences with other people is another one of his lifetime goals.See all speakers ›