Showing posts from October, 2021

Is Meta's Metaverse really what the world needs right now?

I started blogging in the late 00s to write about Transhumanism, Technology, and Virtual Reality.  Technology has always been a passion. Growing up in the 80s I lived through an incredible evolution of electronics and computing. Mass mobile communication was a science fiction wonder I read about in the technology magazine Quest . My internet was Teletext , I wrote letters to pen pals. It was a time of hope and wonder for what the future of technology could bring. Until the last few years, this wonder has continued. Smart phones have brought us closer together, and the digital world has matured into a significant piece of our lives. I think it was the Apple watch when things changed for me. The iphone was an incredible, though incremental, world changing gadget. We all know that. But when the Apple watch was announced it became obvious that these technology companies had peaked. They were no longer about pushing boundaries, they were no longer interested in trying to evolve society with

Unit Tests - Keeping them clean and simple

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

Writing Good Acceptance Criteria

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