Community Blogs

Depender is a tool that I created to illustrate several concepts both for my book and both for my training classes. I think it should prove valuable (as it gets more and more features) to anyone who is trying to write tests for existing code.   Depender allows you to load an assembly and inspect the types within it according to very simple rules. the main question on my mind and I run it is: "How easy would it be to test class X?". Depender will list all the classes in the assembly and for each one will try to detect possible testability problems (non decoupling) and places where you might be able to "inject" your own implementation (calls to virtual methods, fields that are interfaces or types who are not sealed..etc...

This is an interesting problem I've been running into at work. Sometimes we would try to write a test against the system or a component and we would literally have too many choices of how to write it or where to "intercept" or "inject" our stubs or mock objects.  In a way, the software is almost "too testable" in that there is usually at least 3 ways to accomplish a similar level of isolation. What it comes down to is the fact that for a real system, there are different "depth" layers where indirection can be injected. For example, Component X needs object Y that relies on object Z. If we were testing component X we could "replace" either Y or Z.  Some would argue that replacing...

My interview at teched us on advanced unit testing and legacy code can be seen here: http://msdn.microsoft.com/en-us/events/teched/cc676818.aspx   or downloaded here We occasionally stop and laugh a bit because "speaker idol" contest was being held at the booth next to us, which was really really loud.  Read More...

This great news was just published at the alt.net mailing list. putting it here for future reference. "Fixture Gallery 2.0 (release 2008-06-09) is now available for download from SourceForge. Fixture Gallery is a cookbook for FIT/FitNesse tests. It provides developers with a quick overview of the most important fixture types and concepts for agile acceptance testing using the FIT framework. For each fixture type, this document explains the table format and fixture class structure and provides advice when to use and when not to use it. Each example is accompanied by the source code for Java, .NET and Python FIT implementations, in a form that can be easily copied and used as a template for similar fixtures. Version 2.0 brings: - Python examples...

Here's an analogy I came up with to explain the difference between unit tests and integration tests. Imagine going to a restaurant with a bunch of your friends. there are some couples there as well as singles. At the end of the meal, it is time to pay. Unit testing is like giving a separate bill to each couple or single. Each person knows only what they needs to pay as well as tip, but do not care what anyone else had, or what the total meal amount is. as long as they pay what they need, they can go home peacefully. Integration testing is like giving one big check to the group, with everyone having to calculate on their own how much they need to pay. sometimes everyone things they are good, but in the end the total amount may be too high...

As part of My Book I have a chapter on the challenges of integrating unit testing practices into an organization. One of the sections deals with "Tough questions and answers". In short, what are the tough questions you will have to deal with when introducing unit testing. here are the questions I've come across but I'd love to see if there are some that I am missing. Also, I am looking for great answers and references as responses to these questions. Your comments are appreciated: 1 How much time will this add to the current process? 2 Will my QA job be at risk because of this? 3 How do we know this is actually working? 4 How much time will this add to the current process? 5 Is there proof that unit testing helps? - any other...

Eli Lopian, Typemock CEO and awesome Coder, just created a nice little API wrapper around Typemock Isolator that would allow a very simple and readable "Swapping" effect between classes. It would allow you to write code like this:     [ Test ]        public void SwapStatic_CallsFake ()        {            Swap . StaticCalls < TypeA , TypeB > ();            Assert . AreEqual ( 2 , TypeA . StaticReturnOne ());            Swap . Rollback ();        }         ...

This NullObject Factory from Paul is very nice, simple and clean in its design. I really like it and I can see many uses for it, in parallel with working with your standard mocking framework or IoC Container Implementation .   here is a little usage example (last line): var controller = new AccountController( // Class I am testing mockCustomerRepository, // Class I am mocking NullObject.For<ILogger>() ); // Who cares about logging! Read More...

Today was both a good day for e and a bad day for me. Good day because I managed to get a full suite of tests that were somehow failing to work again after a refactoring that got out of hand. Bad - because out of all the tests, one of them failed. Here's the part I'm ashamed of: I was working with a pair, and when we both looked at the failing test, I went out and said "Oh, I think this test is no longer valid. It may just need to be removed". We both knew it was still a valid test, that for some reason was failing. But I was on such a role with making everything work, that test was feeling like a thorn in my thumb that I wanted to get rid of. It was a hard few minutes to convince ourselves to debug through the test and realize...

In regards to my post about injecting mocks and stubs using a container in your tests, Dave asks in the comments: Why would you want to do this in the first place? Here are the things I can think about right now (pros and cons). I'd love to hear your thoughts. Pros for using a container in your tests: Can lead to easier test maintainability . You can add new dependencies to object under test without worrying about existing tests that use that object, since those dependencies will usually be automatically stubbed out as part of the object creation process Allows easier focus on testing interaction. When you have a class that has 3+ dependencies, you'd usually want to have no more than one mock against which you'll test the interaction...