Stephan Schmidt
I Had a Great Idea - E2E Testing For Free
My brilliant idea to combine DX with E2E testing
Part of my CTO Coaching
Today a lot is said about developer experience (DX) to increase satisfaction, retention and productivity.
One pain point in many development organizations is data setup. Developers often need to use the UI to get the systems into a state to work with. They need users and customers and offerings in place to develop new features and test them. They often need to reset data after making some changes to the data to start new.
Alternatively to developers creating data through the UI, production data is pulled in and anonymized. Though that is often slow, error prone, poses security threads, privacy concerns, breaks often and doesn’t reflect the latest data.
When your organization reaches around 10 developers it is time to think about dedicated developers who look into developer experience (DX). One problem to solve is to create tooling, to make everything easier. Bigger companies like Google have excellent tooling. They often invest more in tooling than into writing their own frameworks, whereas small companies spend too much time writing their own frameworks instead of investing in smoother and better tooling. Reading Hackernews comments is often about “how great the tools were”. Investing in DX reaps big returns. One such tool is to make data setup easier for developers.
After experimenting with data setup through tools, SQL dumps, UI replays, E2E tests and other ways, I tried a different approach. For Inkmi - CTO dream jobs I have been creating a Go application that deletes the database and creates usable data for several test users. One user who has registered but entered nothing, one who filled in some data, one who filled in lots of data and so on.
The data is created through calling the normal code of Inkmi, for example CreateCtoProfileUC. This way all side effects happen and the database is in a state that is the same as if a user would have created the data with the UI - because it uses the same code.
For convenience, in development mode, I also print out login URLs and deep links for easier access when the Inkmi server starts. Going directly to where they need to be, is just one click away for developers.
Here it comes! Recently I had a brilliant idea I have added. When the setup is complete, before exiting, the code checks the database state for the number of entries in each table, for existing records in tables and more. This way the data setup also acts as E2E tests. Imagine for development setting up a customer that has a recurring subscription, that renewed twice and who has paid two invoices that you can use as a developer. Checking if everything is in the right state acts as a smoke E2E test for invoicing and subscription renewal. As the developer needs data for the most important parts, the most important parts are tested.
And because developers run this all the time, and it helps them do their work, they will keep the tests working. Without benefiting developers directly, E2E tests often get neglected, break, are not fixed and then deactivated.
I call this DX motivated E2E testing :-)
