Automated Testing Isn’t Just for Business Logic

I had a conversation with Kelly Sommers the other day that was partially a short support group session on the annoying tendencies of development teams to completely lose focus on the architecture and design principles of a system and let the code base devolve into a ball of muddy spaghetti. One particular area that we discussed, and it’s one area I’ve detailed elsewhere, has to do with layers.  Our gripe was that developers seem to completely ignore layering principles once they start coding and introduce cycles, put things in the wrong layer, etc.  A brief recap of layering principles:  Types … Continue reading Automated Testing Isn’t Just for Business Logic

Testing Strategies Involving Async Functions

Some things to keep in mind when writing units tests for code that use async methods: You’re not trying to test the framework’s “awaitability” and you’re not trying to test framework methods that are “awaitable”.  You want to test your code in certain isolation contexts.  One context, of course, is independent of asynchronicity–do individual units of code that don’t depend on asynchronous invocation “work”…  e.g. “Task<string> MyMethodAsync()”, you want to have a unit test that make sure this method does what it’s supposed to do (one being it returns a “valid” Task<string> object, the other being that individual side-effects occur, … Continue reading Testing Strategies Involving Async Functions

Location of unit tests.

I had a short  conversation at Alt.Net Canada about the location of unit tests.  I personally tend towards a distinct unit test project.  But, I deal with mostly commercial, off-the-shelf (COTS) projects where I simply can’t ship code like that.  I also don’t want to wire-off the unit test via #if because I would then be shipping something different than that which was tested. From an enterprise application point of view, this is different.  I would have no problem including the unit tests within their respective project as production code