Speaker

Jan Van Ryswyck

Jan Van Ryswyck

Software craftsman / Technical coach at Principal IT

Brecht, Belgium

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

  • Information & Communications Technology

Topics

  • Test-Driven Development
  • Unit testing
  • Agile software development
  • Extreme Programming

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

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. When zooming in further on unit 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?
Then there are also two different approaches to TDD. Which of these should we choose? There’s a lot to learn about a seemingly simple practice as Test-Driven Development. In this talk we’re going to discover why it’s important to find a 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.

Jan Van Ryswyck

Software craftsman / Technical coach at Principal IT

Brecht, Belgium