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.
Extreme Programming - The Knowledge We Lost
In 1969, Neil Armstrong and Buzz Aldrin were the first humans who set foot on the moon as part of the Apollo 11 mission. This was the culmination of a race to the moon that spanned more than a decade, which went hand in hand with tremendous technological advances. After the Apollo 11 mission, there were six more crewed landings on the moon between 1969 and 1972. Let’s fast forward to today. How many crewed landings happened on the moon during the last 10 years? Not a single one! One of the reasons that there are no more moon landings happening today, is that we simply don’t know how to do it anymore. Basically, we’ve lost the knowledge to go to the moon!
In the early 2000’s, the Extreme Programming (XP) methodology introduced a bunch of core practices that are fundamental to building high-quality software. Many software teams have learned and adopted these practices and made them their own. During these past two decades, many of the XP practices have evolved and will continue to evolve in the future. On the flip side, there’s a growing amount of software teams that have adopted watered down versions of XP’s core practices, to the point that they have lost their meaning and usefulness. This is quite unfortunate, as these teams are missing out tremendously in delivering value to their stakeholders. As the adoption of these watered down practices continues to spread, the software industry is losing a lot of the learnings that Extreme Programming has gifted us. Just as what happened to the moon landings, if we don’t study, learn and adopt the original core practices of Extreme Programming, we will lose this valuable knowledge.
In this talk, you will learn about the origins of Extreme Programming, how it came to be and which problems it solves. We’ll go over each of its core practices, discuss the value that they bring and where to take them from there. Gaining a deep understanding of XP will pay dividends for every software developer’s career. This talk will get you started on this journey.
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