Testing

So, you’re writing automated tests (hopefully). Maybe your team can’t agree on how to name tests, or maybe you’re working solo and not sure the common conventions other people are working with. Plus, naming tests can be hard, and following some guidance can be helpful in figuring out good test names. In my opinion, good

While I use .NET examples for this post, this testing practice is actually language-agnostic and can be carried over to any language. Naming your variables in a clear way is an important part of any kind of code you’ll write, and the code for your tests is no exception. Eventually, if you need to perform

If you’ve ever tried to mock out claims in C# with something like Moq or NSubstitute, you may have already gone through trying to mock HttpContextBase, then ClaimsPrincipal, then finally ClaimsIdentity with some Claims. As you can see just from that alone, it’s a bit of a hassle to chain all the mocking to finally

Overview Keeping your tests clear and readable is an important part of writing good tests, but sometimes, you may find yourself needing some more complex test cases that you find less than clean. One example I repeatedly run into that doesn’t seem to lend itself to clean test cases is testing string parsing methods. xUnit

The problem with static IO methods in C# The System.IO namespace in .NET provides a lot of helpful methods to interact with a file system, but a drawback of them is that many of these methods are static. This is fine for integration testing, where you can test using real files (which probably live inside