We aren’t the only ones who have hit this issue - there’s an issue filed from the end of 2019 as well. Second, Pester needs updated documentation on the topic. Getting a fresh pair of eyes on a problem can help as the primary developer walks the new person through what is happening, revealing assumptions and uncovering hidden dependencies. We did this over Microsoft Teams while self-quarantining in our own residences (we also live in different states). There are two main results from our experience.įirst, pair programming (more specifically, pair debugging) is a wonderful thing. This creates new behavior for any existing command within the scope of a Describe or Context block. I did find a line at the start of the help for Mock that was definitive. The help for Assert-MockCalled and related Assert-’s did not shed any light either. In the wiki, sections about Describe and Context both state that when they go out of scope, any mocks inside are cleaned up. There was nothing in about_Mocking and the docs are in transition from the GitHub wiki to v. Once we had a good understanding of what was happening, we looked deeper into the docs and GitHub project to see if we could find anything that documented that behavior. The one test that had differen parameters just added uncertainty to the experience. Why were we only seeing an error for the mock being called twice? Well, two of the tests construct web requests with the same parameters - so it would always fail on that second test. If there are no mocks available, the real. For the first test, we saw one URI echoed out. If Pester cannot find a Mock with a matching parameter filter, it will default to a mock without a parameter filter. This led to us seeing each test evaluated all the previous Invoke-RestMethod calls within the Context. We looked at the documentation for Assert-MockCalledĪfter none of that seemed to shed any new light, I suggested putting a Write-Host "Assert-Mock with $uri line in the parameter filter of the Assert-MockCalled of the failing test.We changed the mock definition from inside the It to the Context.We added logging in the mock to see how often it was being called as the tests ran (it was firing once per test).We looked at the function definitions and any functions those called and talked through the logic.First, we shuffled them around and it was always the second or third test that failed with the same error.When we ran the tests, the third test in the block would fail by reporting that the mock of Invoke-RestMethod was called twice. The exact tests didn’t matter so much, but I’ve included them below to give you an idea of what the structure looked like. Each test had a Mock inside of their It block. There were three tests in a Context block. The tests were for a command in the VSTeam module.
I was minding my own business, when Donovan Brown ( twitter, blog) DM’d me on Microsoft Teams to ask for a second pair of eyes to troubleshoot a test case that was failing.
0 kommentar(er)
