-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Build before testing/analysis #3
Comments
This is solved with an Imports file: https://github.com/techthoughts2/Catesta/blob/master/src/Catesta/Resources/Module/src/Module/Module.psm1#L4 It permits availability of all script or globally scoped variables.
There is a drawback to this approach. The test function needs to import the module. In current form, that imports the de-constructed psm1. The benefit to this is that you get the ability to run individual pester tests against one function. If your change were implemented, the pester function test would need to be updated to reference the build location. That means you would have to run a build locally every time you wanted to test a function during development. For unit testing I feel like that is not a trade-off worth taking. I'm open to discussing if you have an idea of supporting both scenarios. I do agree that you make a valid point for infra tests. I will pop a new issue to have infra tests moved to post build. |
Ensuring the Tests import the module is pretty easy, just add the build output location to the beginning of your PSModulePath as part of the build process and you'll always import that version first. That way you don't care about where the module is output and you can test the whole thing easily. As a way to test individual functions, my approach for that has been to tag the Describe blocks for each test script with the name of the function it's testing, that way I can run my build script with a
That was just one example of possible issues with this approach. There's also the length of time it takes to import dot sourced modules, it's not a huge amount of time but can get to 1 - 2 seconds easily per import. Not an issue for an end user usually but if you're running 10+ test scripts it adds up and anything that can be done to speed up the build and test process is well worth it. |
Description
If you test the individually and then build the module you aren't accurately testing the code that you're shipping, simple things like $script: or $global: variables may be set in functions that break interactions in other functions but pass the tests. There are also other more complex interactions that can occur with the dot sourcing process (assuming the individual function tests are importing the psd1 or psm1 rather than just the individual function file) which don't occur when all the functions are in a single file.
Describe the solution you'd like
Have the test and analyze steps depend on the build step. It takes a tiny amount of time to combine the ps1 files into a psm1 so it's well worth doing it first.
Additional context
As a side benefit this will also speed up tests which import the module with -Force since dot sourcing is really slow. It'll not be noticeable for small modules but for bigger ones or ones with lots of tests that many imports will have an impact on test time.
The text was updated successfully, but these errors were encountered: