

Jan Van Ryswyck
Software craftsman / Technical coach at Principal IT
Brecht, Belgium
Actions
I'm a professional software developer since Y2K. A blogger since Y2K+5. Author of the book "Writing Maintainable Unit Tests". Provider of training and coaching in XP practices. Curator of the Awesome Talks list. Thinking and learning about all kinds of technologies since forever.
Area of Expertise
Topics
Workshop - Fast Feedback Development By Avoiding The Fallacy Of Integrated End-To-End Tests
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 finishes, 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 UI test.
These are just a small selection of the joys software developers experience while working with UI tests and other kinds of integrated end-to-end tests. Why do we keep doing this to ourselves? In this hands-on workshop, we’re going to address the underlying issues caused by integrated end-to-end tests. You’ll be able to practice how to apply trustworthy collaboration and contract tests to gain the same level of confidence as integrated end-to-end tests without all the hassle.
Refactoring Legacy Code Guided By Approval Tests
(This is a hands-on lab with limited capacity)
You’ve been asked to add a new feature to an existing application. After some investigation, it turns out that the design of the code is far from optimal. There are also no automated tests to help you. Sounds familiar? So you set out to add some tests, but that requires refactoring the code. However, in order to refactor the code you need have tests in place. How do we break free from this cycle?
In this hands-on workshop you will learn how to use Approval Tests for testing legacy code using an outside-in approach. You’ll be able to practice how to safely refactor the code while also adding fine-grained unit tests and eventually introducing a new feature.
Well-Balanced Test-Driven Development
Have you heard about this practice called Test-Driven Development? When asked this question, the most common response is “I’ve heard about it, but never used it in my day-to-day work” or “I only write tests after the production code”. While popularised by eXtreme Programming in the early 2000s, the practice of TDD is in a steep decline. So in order to prevent this loss, we have to rediscover the basics of Test-Driven Development. Although the premise of Red-Green-Refactor sounds easy enough at first, there’s a lot more to it than just writing a failing test, making the test pass and refactoring the code a bit.
For starters, 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? Then there are also two different approaches to TDD itself. Which of these should we choose? What about test doubles? How do I find a good boundary for my unit tests? In this talk, we’re going to start from the history of Test-Driven Development all the way to why it’s important to find a good balance in TDD and how to accomplish this.
Talk - Fast Feedback Development By Avoiding The Fallacy Of Integrated End-To-End Tests
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 finishes, 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 UI test.
These are just a small selection of the joys software developers experience while working 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.
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top