best-practise

Building high quality end to end acceptance tests suites is hard, and creating API stubs (aka mock servers) can be surprisingly time consuming. WireMock.net can help speed this up. E2E testing is hard End to end testing is hard for many reasons, but I think one of the most common is that the developers under estimate how much time to allow for it and then rush the job. Most E2E test harnesess I have worked on, (including several I wrote myself!...

This post is a follow on from Implementing a simple retry pattern in c#. Tasks, async and await are rapidly becoming be default API flavours in many dotnet libraries and the performance benefits for IO bound code have been well documented. However if you need to apply the retry pattern to some async or task returning method invocation you need to watch out for subtle errors. I’ll outline the problem and revise my solution from the previous post....

TL/DR If you want your pull requests to be taken seriously you probably need to learn some more advanced git features like interactive rebase and squash. First I wanted to share an article I found when helping folks that struggle with code review/pull request comments like “Can you rebase that” or “I don’t want to see all your workings – please squash your commits”. If that applies to you, I suggest you have a read of Git Interactive Rebase, Squash, Amend and Other Ways of Rewriting History....

In addition to my previous post about how to do better code reviews below is a list of specific things to watch out for during code reviews, in no particular order: All the CI builds are green The diff/pull request should be small enough that it is reasonable to review it in under 30min - avoid giant whitespace changes. The entire app build is scripted and available with one click/script CI builds are clearly named and well organised, with separate build/test, deploy and acceptance tests stages Deployment is 100% automated New code does not introduce unnecessary duplication....

Code reviews, the process of showing your hard work to another developer and having them tear it to shreds, are often an unloved part of the modern development cycle. The project manager asks why you would change the working solution, the tester refuses to test something twice, and you have to make your colleague admit on closer inspection their masterpiece has an awful double chin. However it doesn’t have to be that way; code reviews can become part of the daily process and you and your colleagues might start looking forward to showing each other work and sharing knowledge....