Andy Butland

Cross-posting an article summarising some recent blog posts from here on making practical decisions around unit testing , written for Zone's blog.

I think this will be the final post in this unplanned series on "Practical Decisions on Testing". Previously posts have covered: Considering a Unit Code coverage metrics Trading off value with difficulty In this post I wanted to consider the topic of test driven development (TDD). It's a technique that tends to divide developers into two camps, those that swear by it, and those that don't touch it (even if they are on board with unit testing itself). Over the course of my career I've used it on occasion, and found some value, but on balance find I fall mostly into the "tests after" camp, and the method of using tests to drive the design of the code isn't something that's really become part of my programming workflow. In particular, going the full TDD approach where you write code that doesn't initially even compile isn't something I've found grabs me, perhaps due to my background in statically typed languages, primarily C...

Without intending to when I started, I've three posts on a topic now, which I think constitutes a series on "Practical Decisions on Testing". Previously posts have covered: Trading off value with difficulty Code coverage metrics As with the above two posts, the intention I've primarily got is to put down in words some discussions I've had at various times, for a reference and as something to point to. In this post I want to discuss what we consider as "the unit" when it comes to unit testing. For many developers, it's the class, and the mark of good coverage is to ensure that all public methods - and via them, the private ones - are covered by tests. In doing so, there will certainly be a well tested code base. There can be a downside discovered in this though, in that it serves as a deterrent for refactoring at the inter-class level. For example, a decision to split the responsibilities of a class into two to better meet the single re...

Another short reference post on the topic of unit testing, in the spirit of saving your keystrokes , based on a conversation I've had a couple of times concerning unit test code coverage. We're using Sonarqube on a current project, which, amongst other things, will review C# code and determine the percentage covered by unit tests. We're currently running at around 80%, which to me seems a fairly healthy metric. It's not the be all and end all of course in that a high percentage of test coverage doesn't completely diagnose a healthy code base, but, all things being equal, it's a good sign. The question then comes - why not 100%? Not in the naive sense though - there's clearly areas of the code, property getters and setters being the classic example, that you could unit test, but wouldn't get much if any value in doing so, and hence the effort is unlikely to be worthwhile. Rather in the sense that if there are areas that's aren't going ...

I've recently been investigating ML.NET , learning by doing implementing a sample project to try to predict a country's "happiness score" based on various geographic and demographic factors. Cross-posting the resulting blog post shared on Zone's digital output.