stuartdobson.net

In the long running battle between management chasing metrics and developers just trying to get the job done, (hi boss!)  I wanted to provide some less obvious examples of why chasing code coverage is a damaging process.  Why Unit Test Code Coverage targets are bad Code Coverage can be gamed, incentivising low quality tests If the coverage percentage is all that matters, there are many ways to increase that number without actually improving the quality and reliability of the code. Having a test doesn’t mean no bugs - it just means the code is being run by a test, that the pathways through the code are exercised by another piece of code. There’s not really any link in these tests to importance of functionality, or even any consideration of code doing the right thing, just that it’s being exercised. Tests add a maintenance burden In the writing of low value tests written only to satisfy KPIs, developers are actually making more work for themselves in the future.  All code adds a maintena

Another month, another Fundamentals exam 😄 I got this one because it was free after doing some online training through Microsoft. But - it was about time I got it. I've been using Azure since it came out but never got certified because there's a lot of Infrastructure stuff in the exams which don't particularly interest me as a developer. In saying that, I found the exam material high level enough to be interesting and I managed to fill in a few gaps.  Most notably - I enjoyed playing with the Azure Infrastructure map . It's a cool visualisation tool that lets you explore all the Azure infrastructure, all the datacentres, undersea cables, even satellites. You can take a virtual tour of a datacentre and learn about Azure in space! Cool stuff.

Back in January (has it been that long!) I completed the Foundations of Humane Technology course from the Center of Humane Technology . You may have heard of them, they made the Netflix Documentary " The Social Dilemma ". If you haven't watched the movie, it's well worth a watch, delving into the often devastating impacts of Social Media. The course explored how to build technology in a more responsible way to minimise the harmful consequences of the technology you build. It's perfect for technology oriented Product owners and developers like myself, requiring us to think about externalities and unintended consequences, and aligning our values with the products we build. I was made to reflect on how technology has impacted me personally, and realised how my health, cognition and attention were impacted by technology overuse. I was obliged to acknowledge that I am very privileged and lucky, I don’t have any major accessibility issues and my demographic allows me t

  Woo!  This was by far one of the most fun exams I've had to do.  I've learnt a really good overview of Microsoft's AI services. I learnt about Image recognition, Bot framework, Speech recognition, Language processing, Knowledge mining, and more.  I've worked a little with Microsoft's Cognitive Framework in the past. In 2016 my team won our company's Innovation Day prize for building an app which monitored employee happiness. We made it into a joke - Big Brother spying on you all day to determine your emotional state at work by taking a photo of you every few seconds and analysing your emotion. It was a joke, man. Fast forward 5 years and there are companies out there doing this as a business now. How effective it is I'm not sure. Given that I ran Hide the pain Harold through the Emotion Service and he got 99% happiness, I have my doubts. Anyway, there is so much cool stuff you can do with the Azure AI tools. I recommend giving this exam overview a good lo

Tests should be split up by behaviour One behaviour, one test. This means don't test more than one thing in a test. Ideally there should be Acceptance Criteria clarifying each expected behaviour. This gives you a solid starting point, but Unit tests can expand on these scenarios by covering edge cases. Telltale signs of breaking this guideline include: Multiple "Act" steps (this is a big sign) Multiple asserts throughout a test Multiple unrelated asserts at the end of a test Data is being changed after the Act step Using the word "correct" in your test name - indicates vague expectations Don't be afraid to create lots of test methods for a single scenario or unit under test, testing various behaviours. When writing unit tests, you can make a new class for each scenario, this gives you power over the TestInitialize/Cleanup methods, allowing you to keep your tests cleaner. Readability is Everything The number one thing to remem

As discussed in my last article , Writing good Acceptance Criteria gives the Agile team clarity and helps them work towards a common goal, saving time and effort while increasing quality. Now I'd like to dig into the details of how to write good Acceptance Criteria. Behaviour Driven vs Procedural Driven Mindsets Many of us may be used to writing/seeing procedural driven tests; step by step instructions with actions and expected results. Procedure-driven tests are often imperative and trace a path through the system that covers multiple behaviors. As a result, they may be unnecessarily long, which can delay failure investigation, increase maintenance costs, and create confusion. Acceptance criteria, and indeed Behaviour Driven tests, should instead be behaviour driven. This means they should be Declarative , specifying how a system should behave in a particular scenario. Procedural/Imperative: Given the user opens a web browser And the user navigate