If we build code generators for a standardised solution, we will sooner or later need something special that does not fit into the generator. When that happens, we do not need to forfeit the benefits of our automation approach. Instead, we can build on top with hand-written code. Let us explore how we can do this safely.
In last week's post we generated repositories to access our tables. But do they work, or did we overlook something? Let us find out if everything works as expected by generating integration tests for our repositories.
Last week we reached our first milestone by accessing the database with our T4 template and create classes that match our tables (entities). We can now build on top of that knowledge and generate repositories to work with the data in our database.
With the T4.FileManager we got the missing part to create a code generator based on T4 templates that puts classes into their own files. With that problem solved, we can start our automation project and generate classes for all our database tables, generate the repositories to access the data and finish with integration tests to make sure that our repositories work as expected. Let us start with the entity generator.
When we generate code with T4, we end up with one single output file per template. That works if we only generate one HTML page or a single class. But when we want to generate multiple classes, the single output file is annoying. We never would let the developers write code that way; therefore, we should not let the automation get away with it either. Let us look at a solution to that problem.
After exploring the theoretical side of an automation project over the last few weeks, it is now time to get our hands dirty and write some code. There are many options for code generation, but I prefer the T4 templates. We have been using them for years and they are so stable that they form an excellent basis for our automation project.
When we settled with a standardised approach on how to do the work and we simplified it as much as possible, we can finally enter the phase of automation. In this last phase we face a new set of challenges that may left you baffled. Let us explore the traps so that we know what to look for.
Before we dive into making the work as simple as possible, we should have decided on the one way we want to do the work. Make sure that everyone is on the same page, otherwise you will need to repeat the simplification step for every variation of the not yet standardised approach!
Last week we elaborated on the different phases we need for a successful automation project. Today we explore the phase of standardisation in more depth.
A nice side effect of the standardisation is that we get a more consistent output. Instead of the many different ways of doing things, we end up with a single approach and that by itself will reduce the inconsistencies.
There are not many topics in which success and failure are that close together than in an automation project. It does not matter if you automate a process or code generation – it is a small misstep to turn a possible success into a definitive failure. To change the odds to our favour, we should split our automation project into three distinct phases:
While everyone has their own ideas what could go into these phases, let us take the time to define them so that we have a common base of understanding.