In my recent posts, I’ve been exploring how Roslyn-based code analysers can help to make your code cleaner and more robust. I’ve tried to keep it relatively IDE agnostic so far. In today’s post, I’d like to talk about some of the pain-points involved with using code analysers in VS Code, as well as some of the progress being made by the community.Continue reading
In my last post, I talked about why I love code analysers. Towards the end, I mentioned how easy it is to get started, but I glossed over the fact that flipping the switch on an existing application can be a pretty harrowing experience. In today’s post, I hope to make the jump a little easier by walking you through a 4 step strategy that I’ve found helpful on a couple of projects.
Static analysis can be a great way to ensure that your code is robust and clean. Unfortunately, many static analysis tools are prohibitively expensive and/or fiendishly complicated. In today’s post, I’d like to talk a little about Roslyn-based code analysers, which cost nothing and are easy to set up. In fact, keep reading for seven reasons that they’re ace.
An issue was recently raised on the ConTabs project that sent me down a bit of a localisation rabbit hole. You see, I’d written a load of conformance tests that included example output. What I hadn’t factored in was how many of these were dependent on my locale. These would potentially fail on computers with different locales. In today’s post, I’d like to explore exactly what went wrong and how we put it right.
Put on your aprons people – it’s recipe time. Today we’ll be cooking up a delicious batch of automated API tests. For this recipe, you’ll need a buttery Postman base, a squeeze from a random user data API, and a CI system to bake it all in (I used Azure Devops). The result is a set of golden-brown integration tests that use realistic fake data and run in the cloud on a schedule of your choosing. Sound like the sort of recipe you’d like to master? Read on… Continue reading