Today I’ve finished implementing the mVC (the “m” is purposely lower-case to indicate me not implementing it) helper classes to outsource the burden of finding the components one in respect to the other. While the classes may seem diminutive in lines of production code the tests really took some effort to write.
In many tests I could have taken the easier road to use loops and conditionals to populate them but a balance between possible input coverage (generate many test) and test readability (tests are literally written line by line) had to be drawn.
Unit all green, time for integration
Even if the unit testing gives all green it does not mean that the the helper classes will nicely get along. To test cooperation-among-the-helper-classes cases (I had to struggle to find an integration synonym) I will have to set-up some realistic interaction among them, I’m not going to test any possible combination, and will do that in code.
Codeception to be precise.
Setting-up integration testing in Codeception will require, in my case, generating the integration suite
codecept generate:suite integration IntegrationGuy
and then generating, inside the recently created integration suite, a first integration test
codecept generate:test integration SomeIntegration
and set the tests/integration/_bootstrap.php file to actually include the classes under test
Choosing what to test
I’m not maniacal about full code-coverage or testing any possible combination in code: I will set-up tests for cases I can think of from the top of my head and will use this simple rule to know when the top of my head is exhausted:
If I can't think of a test in 30 seconds then the top of my head is exhausted and the tests I've set will do
I don’t do that at 6pm or nothing will come out.
Luckily, in this specific case, the helper classes were made to out-source the namespace and filename resolution that’s actually made by the Main and Controller classes and I will simply use the code I’m going to replace in those classes as a guide.