Testing

In the past, testing the data layer was hard, really hard. It would include a test database, as opposed to the production which of course we didn’t want to use for testing. Maintaining any sort of consistency was a pain to do, and perhaps fell by the wayside because it was too tedious and too fragile. Then we used in-memory databases, but the only viable ones were HSQLDB or H2. The problem there though is that the SQL for the in-memory databases didn’t quite match up. Today we have Test Containers which uses a Docker Client to download a specific version of whatever database or messaging system you wish to integrate. The best part, you can test against the same version of the database or messaging system so you have higher confidence that your tests work.

In reality, our jobs aren’t dealing with new code, but old crufty and evil code. How do we test such code, how do we get through it? How can we surgically take some of this bad code apart and make it testable.

Property Based testing is letting the computer determine aggressive inputs for your subjects. When the computer provides edge cases, it highlights some of the typical problems that may still show up, so that you, the programmer, may have not thought about.

Test-Driven Development is a test-first practice that drives the code through tests. It is a simple practice but not an easy practice.

The details are what gets you. This presentation introduces you to Test Driven Development, how to get started, what modern tools are available, and the challenges you will face.

We have been using JUnit and doing TDD for years, but you can take testing further. In this session, we will discuss some tools you absolutely need for testing your code outside of the regular stack you currently use.