Hello! Last week we spent some time in the office here getting to grips with Pester. I’ve written some Pester tests in a few projects I’ve got in GitHub, most notably PoshSSDTBuildDeploy (henceforth known as PBD) and have them running in the VSTS CI build here and the Publish build here. So I felt I was quite familiar with Pester testing. But one thing I had missing in my tests was mocking.
Hello! I recently updated the script that uses both the TeamCity and Octopus API’s to raise defects if a TeamCity build has failed (the reasoning here is tat a deployment has passed on Octopus, but subsequent automated testing has failed.) This script uses functions and is a little neater than the previous version. You will have to create a snapshot dependency between the build that this step runs in and the build that deploys/runs the tests.
In my previous post, I shared a script that used the Octopus API to create a defect, with the aim of it being added to a TeamCity build and chaining the build to a deploy/test build step in TeamCity: the aim being to raise an Octopus defect if a test fails whilst the deployment to the environment succeeded. You can read more about it here.
What makes this a challenge is that there is no way to have a chained build that runs if, and only if, a build has failed. So as with Octopus you have to use the TeamCity API. In this script I get the the status of the last build that deployed/ran the tests, and if this build succeeded I do nothing. So yes this chained build has to always run post deploy/test phase.
Where it gets interesting though is if the build failed. Here we raise a defect, but not before checking to see if there are any defects raised that are still unresolved, as only one Octopus defect can be unresolved at any one time.
Unit testing can sometimes throw up unexpected issues that are entirely concerned with the unit tests and not the application under test. Recently I’ve been having issues with DateTime formats affecting the results of the unit tests: the format of the DateTime was different on the build server than it was on my local machine. The stored procedure could not be altered (because reasons*).
Hello!
(Guest blog by Testing The Waterhouse)
Firstly, let me introduce myself, my name is Gareth (author of Testing The Waterhouse), I’m a Senior QA Engineer and started working in QA the same time as Richard for the same company. I got into QA for similar reasons to Rich, I’d graduated and was finding it hard to get a job so ended up working for a small consultancy firm as a QA analyst.
When Richard got in touch with me a couple of weeks ago about guest blogging on his blog, I wasn’t really sure what to write about, seeing as he used to be a tester, but has moved into the DevOps world. I started reading The Phoenix Project, so I could try and gain an idea of what his new world is like, unfortunately, I’m only half way through, so didn’t really want to write a blog post about that…