Golo Roden

How not to test

If your code is hard to test, it's not because the problem is complex. It's because the code itself is poorly structured.

How not to test
#1about 6 minutes

The journey from manual execution to automated testing

Early programming involved manually running code to verify it, but the rise of concepts like Test-Driven Development (TDD) introduced the power of automated testing.

#2about 7 minutes

Difficult-to-test code is a symptom of poor design

Code that is hard to test is often a sign of poor structure with too many dependencies, not an inherent problem with the complexity of the task itself.

#3about 6 minutes

The pitfalls of testing private implementation details

Avoid trying to test private code directly through hacks like reflection, as tests should focus on the public behavior and interface of a component.

#4about 5 minutes

Why 100% code coverage is a misleading metric

Achieving 100% code coverage is often a false positive because it only confirms code execution, not the quality or relevance of the tests themselves.

#5about 5 minutes

The dangers of overusing mocks in integration tests

Relying heavily on mocks can create a false sense of security, as they may not accurately replicate the behavior of real dependencies like databases.

#6about 2 minutes

Ensuring test independence with clean infrastructure setups

Tests should be independent and start from a clean slate by automating the setup and teardown of infrastructure for each run using tools like Docker.

#7about 4 minutes

Handling asynchronicity in UI component testing

UI tests must account for asynchronous operations like animations and transitions, as assuming synchronous behavior will lead to flaky and unreliable results.

#8about 4 minutes

Writing story-based UI tests instead of fine-grained ones

Full UI tests using tools like Selenium are slow, so they should focus on broad, story-based user flows rather than fine-grained component interactions.

#9about 3 minutes

Applying Test-Driven Development (TDD) strategically

TDD is most effective when you have a clear goal and can be counterproductive during prototyping; it's best to explore ideas first, then rebuild with TDD.

#10about 2 minutes

Adopting a reasonable and pragmatic testing approach

The goal of testing is not perfection but to provide reasonable confidence, so focus effort on what is valuable to test rather than blindly chasing metrics.

Related jobs
Jobs that call for the skills explored in this talk.

Featured Partners

Related Videos

See all videos
How To Test A Ball of Mud42:34

How To Test A Ball of Mud

Ryan Latta

Continuous testing - run automated tests for every change!47:22

Continuous testing - run automated tests for every change!

Christian Kühn

Your Testing Strategy is broken - lets fix it!28:12

Your Testing Strategy is broken - lets fix it!

Luise Freese

Test Driven Development with JavaScript1:42:16

Test Driven Development with JavaScript

Sascha Depold & Parinaz Roghany

Write tests you love, not hate56:49

Write tests you love, not hate

Jens Happe

How to add test automation to your project: The good, the bad, and the ugly26:20

How to add test automation to your project: The good, the bad, and the ugly

Augustin Gottlieb

How Unit Testing Saved My Career26:33

How Unit Testing Saved My Career

Annelore Egger

The 2025 State of JavaScript Testing28:33

The 2025 State of JavaScript Testing

Daniel Afonso

From learning to earning

Jobs that call for the skills explored in this talk.