Actually each of our tests should test only one aspect of the problem and all the other aspects should be stable. After all, we want our test suite to be as stable and as independent from the real world as possible. Not being certain about the environment in which our tests run is a huge problem. A file can be deleted, renamed, moved, locked for access or made unavailable in a different way. The second thing is: Testing your code with PowerShell is difficult, because PowerShell is all about dealing with real world resources. To keep all the information in the previous two articles relevant I decided to use the same major version as with the previous two articles. There is also a new 3.0.2 version available in the master branch, packing a lot of new exciting features, but bringing few breaking changes at the same time. In other words detach it from real world resources.īefore we have a deeper look at how exactly the Mock is used there are two things you should know: The version of Pester used in this article is the stable 2.0.1+ version you can find in the master branch on Github. This comes in handy when you need to force the code under test to a stable predefined state. This function lets you hide any function with a fake implementation of your choosing, count how many times it was called and filter on parameters of the call. In this part of Pester basics series, I will cover the most powerful tool from the whole framework, the Mock function.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |