Unit Tests

There are 4 entries for the tag Unit Tests

Moq Sequences Revisited

A while back I wrote about mocking successive calls to the same method which returns a sequence of objects. Read that post for more context. In that post, I had written up an implementation, but quickly was won over by a better extension method implementation from Fredrik Kalseth. public static class MoqExtensions { public static void ReturnsInOrder<T, TResult>(this ISetup<T, TResult> setup, params TResult[] results) where T : class { setup.Returns(new Queue<TResult>(results).Dequeue); } } As good as this extension method is, I...

Research Supports The Effectiveness of TDD

In a recent post, Frans Bouma laments the lack of computer science or reference to research papers by agile pundits in various mailing lists (I bet this really applies to nearly all mailing lists, not just the ones he mentions). What surprised me to no end was the total lack of any reference/debate about computer science research, papers etc. ... in the form of CS research. Almost all the debates focused on tools and their direct techniques, not the computer science behind them. In general asking ’Why’ wasn’t answered with: "research has shown that..." but with...

Using WebServer.WebDev For Unit Tests

Last night a unit test saved my life (with apologies). Ok, maybe not my life, but the act of writing some unit tests did save me the embarrasment of an obscure bug which was sure to hit when I least expected it.  It is cases like this that made me into such a big fan of writing automated unit tests. Not too long ago I wrote a C# Akismet API for Subtext. In writing the code, I followed design principles focused on making the API as testable as possible. For example, I applied Inversion of Control (IOC) by having the AkismetClient constructor take...

Structuring Unit Test Code

UPDATE: I’ve since supplemented this with another approach. Jeremy Miller asks the question, “How do you organize your NUnit test code?”.  My answer? I don’t, I organize my MbUnit test code. Bad jokes aside, I do understand that his question is more focused on the structure of unit testing code and not the structure of any particular unit testing framework. I pretty much follow the same structure that Jeremy does in that I have a test fixture per class (sometimes more than one per class for special cases).  I experimented with having a test fixture per method, but gave up on that as it became a maintenance headache.  Too...