Closed srmurguia closed 6 years ago
Maybe it is worth to add "annotations" parameter to the "MethodBlueprint"? Then a test would be another MethodBlueprint
and ClassBlueprint
can have a list of testMethodsBlueprints
that will be used to generate test class?
It is possible to go even one step further, we can treat tests for a class as another class and make an instance of ClassBlueprint
for it, then PackageBlueprint
can have a testClassBlueprints
along with implemented classBlueprints
.
What do you think? Does it sound reasonable or it is too much complexity for nothing?
I thought about having a separate ClassBlueprint for test classes, but I decided to not do so because all the information needed to create it already exists on ClassBlueprint and MethodBlueprint (and right now there is a 1 to 1 correspondence between classes and test classes).
As you mentioned on the other comment, this decision and the way I implemented it caused some code duplication, I will improve that part. I will create a new commit using testClassBlueprints and see how the code looks after that change and then we can decide which one is better (current implementation would save some memory, but separate classes will be cleaner, I think)
Latest commit implements the suggestions made by Nikita, there are classBlueprints for every test class.
LGTM, I didn't do QA
Now tests are also created if generateTests is set to true.