I've opted to separate out the changeset author's email into its own object property, so that brings the project up to 1.6.7. (1.6.6 added optional parameters to new-psdrive to set the number of changesets and changeset manifests to cache.)
Unit Testing
Since 1.6.6 there have also been a few other improvements, but most have been minor (cache edge cases) or stylistic refactors. Most notably, the code now has unit tests. The PowerShell Provider classes, while making the actual coding pretty simple, don't make unit testing easy to accomplish through the usual dependency-injection paradigm. The classes have readonly this, private that, and no public constructors or setters.
I worked around it by replacing the code's dependencies with protected properties and then creating slim subclasses for my tests (i.e. the well-known extract and override) that overrode the essential properties with unit-test-friendly replacements.
Unit tests also prompted design changes in member and class accessibility. The fundamental purpose of a unit test is to exercise all the exposed capabilities of a class, so in effect the unit test aids in refining the "public face" of the class.
- If all the unit tests can be written without making member X public, then keep X hidden.
- If the unit tests can't fully check the class's capabilities by accessing all the class's public members, then maybe
- some more of the members need to be available to the class collaborators
- the class simply contains "dead code" that no other part of the system will ever access or use
- the tester is trying to test code at a level that's too granular or fastidious
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.