GeeCON TDD 2015

Last friday I had the opportunity to attend the GeeCON TDD conference. It was a one-day event in Poznań. There were plenty of people and a lot of talks. Here is my short recap of couple of presentations.

Test Driven Development: That’s not what we meant, Steve Freeman

  • It’s quite easy to write non-readable tests with TDD:
    • long test methods,
    • long names of test methods,
    • unclear/not informative names.
  • What are the tests for TDD:
    • steady and incremental progress,
    • constant positive reinforcement,
    • think before coding (write what’s needed not could be useful in the future),
    • things break when they’re supposed to (tests as backups),
    • surprising designs emerge (wait till a structure you have in mind is needed instead of speculative coding).
  • Write readable code:
    • name methods so they create a sentence with a tested class name, e.g.
      class Basket { @Test void is_empty_when_created() { ... } }
    • interfaces, not internals: use public API in tests and test how object is working (e.g. in collection-like objects test get() and add() methods together)
    • from simple to general
    • explain domain, do not prove the code
  • When lost, slow down
  • Test at the right level
    • use different kind of tests
  • TDD works, but why?
    • It’s focuses: one thing at the time, let’s not get lost and ask the question: “what’s the minimum to finish what needs to be done?”
    • while an application code is physical design tests of it show logical design
    • It’s concrete: working with examples is easier and safer so get user stories from your customer or business
    • It’s empirical: plenty of questions “does it actually work?” and a lot of feedback (see TDD loop)

Driving well-crafted code through tests, Sandro Mancuso

  • the talk to TDD non-believers
  • right sequence of tests is essential
  • simple constructs first, complex are harder to refactor,
  • intentionally cause duplications in code
    • It’s just easier to find patterns. And while you see them refactor immediately.
  • delay dealing with edge cases
    • Edge cases add complexity.
    • Code happy paths at first.

Short intro of couple of guidelines and live coding showed how to use them in practice. Splitting the screen into two editors is really helpful (one for tests and one for the production code you are currently working on).

Randomized Testing: When a Monkey Can do Better than a Human, Dawid Weiss

  • Motivation
    • “Beware of bugs in the above code; I have only proved it correct, not tried it.” Donald Knuth
    • Assumptions != the Real World
  • A tool worth to check: forbidden-apis, developed by Uwe Schindler
  • David showed three examples where randomisation of test data would be useful
  • Randomized Testing mini-manifesto:
    • each run covers a different execution path
    • each run is deterministic
    • tests are repeated a lot of times
  • What can be randomized:
    • input data, iteration counts, method arguments
    • software components (usage of multiple implementations)
    • environment settings (different JVM versions, locale settings)
    • exceptional triggers like IO errors or network failures (e.g. by using mocks)
  • Downsides:
    • failure reproducibility (concurrency, time-based things)
    • incompatible components configurations
    • tests are typically pretty hairy (to debug or to fix them)
  • Good:
    • complex boundary conditions
    • unexpected component-component interactions
    • unexpected environment interactions
  • The best place when to run randomized tests is CI build
Test Driven Traps, Jakub Narbdalik

  • verify only what the name of the test says
  • only one thing per test
    • have just a single business reason to fail
    • does not mean “single assertion per test”
  • only the behaviour, not algorithm
    • do not pour concrete over your code
  • only the relevant thing
    • does it matter?
  • write code to help your tests
  • build domain as in production
    • so it changes with production
    • e.g. do not provide special constructors for tests only
  • performance is crucial for tests
    • design for performance
    • developers won’t be eager to run tests when they took more than 30 sec
  • what is the unit
    • do not test every class
  • always go top-down
  • tests are normal code
    • don’t do in tests what you wouldn’t do in production code
  • don’t test just for the sake of testing
    • aim for 100% of coverage for domain part of your application
Drop the clutter: lightweight tests with Spock, Piotr Betkier

It was a gentle introduction to Spock actually. All capabilities of the tool were presented. The attendees could see how cool tests can be with Spock. The presenter compared compared testing Java with JUnit to a baroque époque while testing with Spock to enlightenment era.
From my personal experience I advice using Spock in projects whenever it is possible. It is really, really worth to learn the new code syntax.

Java 8 brings power to testing!, Marcin Zajączkowski

It was a nice review of couple of testing tools and a good summary how test code using them with Java 7/8 code can be simplified and/or shortened. The tools mentioned in the presentation were assertJ (there is a separate JDK 8 version as well), Awaitility, Mockito and catch-excpetion.

You don’t run unit tests concurrently. Do you?, Martin Skurla
In this lighting talk Martin showed couple of tips about running tests concurrently:

  • minimise the shared state (this means all fields and logic in setup methods)
  • guard the necessary shared state
  • understand the framework’s thread model
  • external integration also needs to be thread safe
  • prefer test classes over test suites
  • even better: prefer test methods over test classes
Lessons Learned Breaking the (TDD) Rules, Nat Pryce
It was a nice summary of the whole day based on a real-life experience. The most sounded ideas were:

  • TDD is not about tests. It’s about what we will do with our automation tests.
  • What actually we will do with the feedback collected.
  • TDD creates sources of learning the project.
  • TDD is not about tests, its about how they drive your design of the code. Well, maybe this is why there is DRIVEN used in this title.
  • You shouldn’t write the tests just for sake of writing them but listen what are they telling you about the code.

To sum up I have to say the organisers made the grade. Everything worked just good. It was a good one-day event. The only thing that could probably be better is the catering area: for the lunch, it was too small I think.

Despite there were actually no breaking news or revolutionary ideas the conference was a really nice recap about the testing overall and TDD particularly. There were summaries about testing craft and reviews of a couple of tools. A lot of rules and guidelines were presented. However, it seems the most important thing to remember from this conference is one thing that sounded from a couple of talks: sometimes it is worth to break the rules. 😉

Leave a Reply