Repository navigation
How far should we go to make up for missing features in other OSS projects? #3187
Description
Especially with regard to Pester as we rely on it as our test infrastructure, but sometimes Pester does not have a feature which we would like. Should we code up our own solution and use it?
I am very concerned about this because it does not help the Pester community and places a burden on anyone who wishes to use our solution to get one more module, or script. Specifically, when checking for error conditions, we would rather validate against FullyQualifiedErrorId rather than the message (which is what Pester provides). I would be happier to have a PR filed on Pester which implements an assertion for something like ThrowFullyQualifiedErrorId (or similar) rather than coding around this in our own code. This allows Pester to have something generally useful and avoid more and more unneeded custom code.
Activity
lzybkr commentedon Feb 23, 2017
We can provide our guidance and experience to other projects and offer PRs, but we can't make other projects accept our ideas.
We can learn a lot from applying what we think is a better solution by actually implementing our idea first in our own code. When we've worked out the details - we can move on to a PR that works well for us.
iSazonov commentedon Feb 23, 2017
This is the best way to use a Pester major version and improve it. But the current versions of Pester is not ported. pester/Pester#673 Even if the desired improvements already exist, we cannot use them.
Perhaps we should add the migration to a new Pester version in our Plan (6.0 roadmap) because it will be very strange to deploy the latest release of Powershell 6.0 with very old (two year?) Pester module.
iSazonov commentedon Aug 29, 2018
Currently we use latest Pester version which support many new features including
Should -Be -Throw. Also we convert all our tests to use new Pester 4.0 syntax.