About Me

Series Reminder Technology Stack

Front End: HTML5, CSS, JavaScript, jQuery, Bootstrap 5
Back End: Java, Spring Boot, Spring MVC, Spring Security, Spring Social, Spring Data
Testing: JUnit, Mockito, MockMVC, Spring Test
Databases: MySQL, AWS DynamoDB

Testing Philosophy for Series Reminder

Throughout my career, I was never really a huge TDD advocate. Theoretically, I could see the value of it, but it was just not part of the code base and trying to add code coverage to a legacy code base is a daunting task.

Working on Series Reminder has changed my perspective on this. As a one man show, building and running a site like this is a tremendous amount of work. There is no way I can test everything manually, especially if I am upgrading libraries that are used for the whole app.

I have to admit, at first I was skeptical about fully committing to a high test code coverage strategy. It definitely takes a significant amount more time to build something, but it has paid off. Production problems are stressfull and the extra time spent writing the test cases has saved me more than once. The peace of mind it brings alone is worth it.

I strive for 80-90% code coverage on all new code. I find it strangely satisfying to check the code coverage percentage report after I do a production build. It somehow makes me want to go write a few test cases on legacy code just to see the report change.

Flyway Database Migrations

By using Flyway for database migrations, I can treat my test database ephemerally. As part of my Jenkins build pipeline, I simply drop the existing database and create a new one before running all of my application Junit tests.

All of my Junit tests actually read and write to the test database. Having a known set of seed test data when you create a new database works out really great for this setup. Every time I run my tests I know exactly what data is in the database. With Flyway, I can easily load sead data into my test database that will not be deployed to production.

It also tests my database migrations before they are applied to the production database. It definitely sucks when one of these fails in production. And, I can easily modify it to run the migration scripts against scrubbed production data if I need to.

Integration Tests

For me, real integration tests are the most valuable. I have a separate set of integration tests that only run as part of the Jenkins production build process. I can run them locally if I am working on them, but I tend to only run them for production builds.

I do not do production builds every day, so I don't mind using metered cloud resources for some of these tests. They are practical tests, such as writing a file to S3, reading it back, validating it, then deleting it. Doing this kind of testing this is not an activity I want to do every time Amazon releases a new version of the SDK.

Calling out to mission critical APIs are also part of my integration tests. The production application is already making hundreds or thousands of calls a day to these APIs. One more call during the build process is not much to ask to make sure everything is still working okay.