
Johan Martinsson
Biography
Johan Martinsson is a freelance dev coach, passionate about code and software design.
Co-creator of conferences SnowCamp and AlpesCraft, facilitator of regular meetups since 2009, he often finds (good) excuses for showing code at conferences.
NewCrafts Paris 2025
We don’t need no (more) mock trouble
HandsOn
This is a hands-on lab with limited capacity.
π§ͺ Do you really enjoy writing tests with mocks?
Or maybe...
β‘οΈ You had a bug in production even though everything was tested?
β‘οΈ You have to change the test when you refactor?
β‘οΈ Youβre sometimes lost in mock setups?
β‘οΈ Integration with external services is source of bugs?
What if the real problem... were the mocks themselves? π
Johan Martinson and Mathieu Cans are proposing a simpler, more reliable alternative based on their experience:
π Simulators instead of mocks, validated by Adapter Contract Testing at architecture hexagonal boundaries.
π‘ The idea?
- hand-code a simulator that behaves like the real service or database.
- write integration test against the real service β thatβs our contract.
- use same test to validate the simulator.
Result: No more trouble ππ―π²ππ½
β
Robust, expressive, business-focused tests that stay close to reality.
π« No more production surprises because of a badly tuned mock.
π« No more incomprehensible tests.
π« No more unexpected behavior from dependencies.
Previous events
NewCrafts Paris 2019
Rescuing legacy - from legacy to TDD
Small Hands-on
What's the main hurdle of doing TDD in our existing codebase? The difficulty of testing the untestable code of our legacy codebase so that it can be refactored into something where it is easy to add functionality using TDD.
But how is this done when I have no separation of layers, no architecture and I can't even mock the database? Well let's see the workflow through a guided workshop of how tests are put in place, how the code is refactored and then finally how tests are separated into different layers of the testing pyramid, and finally how easy it becomes to TDD the new feature!
This demonstrates not only the basic workflow of modern development with legacy code, but also how we can leverage preparatory refactoring to gain time even in the short term, thanks to testing. Additionally it illustrates how respecting the testing pyramid makes a developers life more pleasant.
Code that makes no sense to unit test due to bad design is a common problem. This small example models this problem in realistic way due to its hard-coded integration with external dependencies that cannot be "stubbed out".
Setup here: https://github.com/martinsson/Refactoring-Kata-Lift-Pass-Pricing.
NewCrafts Paris 2018
Bug Free, by Design
Talk
Get rid of whole families of bugs for good with 21 tricks to reduce the space available for bugs.
Bugs are not a fatality, they appear whenever the design allows for it. Learn how to fix the root-causes and how to give an intrinsic quality to your code.
You'll look at static and dynamic typing in a different way. Learn about NoPrimitives, coupling & cohesion, if-less. We'll talk about the feedback-funnel and how it all scales from micro design to micro-services and to macro-design.
Loads of concrete examples and some live coding
NewCrafts Paris 2018
BugsZero Kata
Hands-on
Bugs are optional, they get their way into our code much thanks the design choices we do or quite often fail to do.
You'll practice reading code, looking for parts where it is likely that a developer would create a bug if he extended the code. Whenever you've found such a weakness in the design your challenge is to strengthen the design in order to make that kind of bug very unlikely, or even impossible!
You'll practice the procedure of
- Identify a weakness in the design
- State what the potential bug is before explaining your solution. This is important, simply saying another solution is better avoids thinking of why it is actually better.
- Explain or refactor the code to show the new design.
NewCrafts Paris 2017
Usable software design
Talk
Did you ever think of the user of your code? Not the one using the application,
but the developer that has to change the code after you. Does that person
have a good tool for the job, i.e. is the code usable?
What can we learn from other domains where the power of user-centric design was discovered
decades ago and led to a win-win situation? Expert designers always repeat that
You're not your user!
and
It's not the users fault, it's the designs fault.
Why? What does that mean in our world of code, architecture and team practices? You can
expect plenty of code illustrating general principles of design and ergonomics. You'll go
home with simple but powerful tools.