This project has moved and is read-only. For the latest updates, please go here.

Why code generation coverage tests?

Feb 12 at 11:43 PM
Edited Feb 13 at 11:15 AM
Let give you the simplest example. I have a few issues (aka defects) that I can't remember how to reproduce. Therefore it will be quite difficult to fix them. At the time I didn't have coverage tests. Now when I find a defect, I write a nice coverage test - I write the code that CslaGenFork is supposed to generate - and then and go to the code / templates and change whatever is needed to fix the defect.

Second example. When fixing some defect or adding some feature, there is the risk of breaking existing features. Those issues are known as regression issues. A comprehensive set of coverage tests lets me find regression issues on the spot.

But the big Why is VB porting. Since the beginning of CGF I have my own private set of coverage tests but it was more like the projects I want to generate using CGF. There was no intention to make a comprehensive set of tests. Porting new features to VB forced me to move to another level.

By the way, the initial port to VB was done by Bill Larman with some help of Pandelis Boyiazis. I'm grateful of their help. But I wanted CslaGenFork to move on and there was no sense in leaving VB generation behind, with the risk of breaking VB code generation. So I took on Bill and Pandelis work. And that was only possible with a comprehensive set of code generation coverage tests for VB.

Code generation coverage tests gives me (and you) confidence ClsaGenFork does its job and won't fail right in the middle of an important project.
Mar 7 at 9:49 AM
After that project i moved to c# myself. It provides better support and the programmers/software market seems more accessible and rewarding.