Community Blogs

I’m writing this as a typemock employee, but also as someone who has sat on the other side of the line for several good years, and can argue in both ways. The following, I feel, is true no matter where I work.   There are two ways people use tests to drive design, as far as I see. one is great, and I agree with, the other is not so great and I don’t agree with it. Sadly, both of them are categorized together these days, and the baby gets thrown out with the bath water - You either use both (BAD) or you use neither (BAD!) Here are the two usage patterns: #1 Willed Design By writing tests, you can observe the usability of your design from a consumer perspective, and can decide whether or not you like it, and change it accordingly #2 Forced...

in continuation to my challenge (which no one had bothered answering, lazy web!) One of the things that inhibits unit tests in organizations is the idea of fragile tests. a Fragile test is a test that can easily break when the production code changes. That’s not to say that tests should never break as you change production code, but there are ways to minimize this effect so that when tests do break, they break for the right   reason. the right reason is when a feature in production code isn’t working. the wrong reasons can be many and varied. Of the most common ones is the idea of over specification in tests. The more your test expects of your code’s internal implementation, the more “specified” it is, the more “expectations” it has on...

Scott Hanselman took me in for a 30 minute interview about Unit Testing Dos and Don’ts in his podcast, Hanselminutes. It was a pleasure, and I hope to be there once more about other topics. Maybe in TechEd Berlin.. Have a listen Read More...

NDC 2009 was a blast! Thanks for all the great conversations :) Here’s what it looked like when you look up at a full room in NDC Read More...

here are the questions that teams and team leads should be asking themselves on a daily\weekly basis. There are more, but these are the basics, to me. It’s part of the summary for the talk “Beautiful teams I am giving at SEConf and NDC. we do a lot of this stuff over at work , and it’s proving itself on a daily basis. Whole team What can we automate? where are we "Reinventing the wheel"? what are the tools that slow us down? what tools can we use better? are there bugs that I could have found earlier? how do I make sure I find the earlier? when do we find out we built the right thing? when do we find out our code\design sucks? how can we make that earlier? How do we show progress at the team level? at the management level? How many...

My book, The Art Of Unit Testing , is now in stock at Amazon. If you’ve read the book, I’d love it if you put in a review on that page. Read More...

What are your thoughts on this style of writing? Specifically the “Explicit” way of defining arrange, act and assert scopes. also, given the name of the test, where should the call to “OnApplyTemplate” be (if you’ve never seen the code)? which version makes more sense to you? A, or B?   version A:     version B: Read More...

This question keeps coming up: “How can I test that an event was actually raised from my class under test?” actually, there is an easy way to check if an event was raised. you subscribe to the event in your test, and in the event handler you set a boolean flag to true. then you just assert on the flag. here is a quick example: Code: public void Test() { bool wasRaised=false; var button = new Button; button.Click += ()=> wasRaised=true; button.DoSomethingThatShouldHaveTriggeredTheEvent(); Assert.IsTrue(wasRaised); }   If you feel less comfortable using lambdas: public void Test() { bool wasRaised=false; var button = new Button; button.Click += delegate { wasRaised=true }; button.DoSomethingThatShouldHaveTriggeredTheEvent(); Assert.IsTrue...

The time has actually come. After 2.5 years, and two kids, my book is finally done and is available in full form as an EBook. at the end of the month it will be in print form. Now would be the time to get it, when it is still at a “pre-order” pricing. Get the preorder price either at Manning (along with the EBook) or at the amazon page . I love the cover image. How about we call this “The Samurai book” from now on? This is the book that I wished I had when I started out writing my first tests, and that combines my knowledge about unit testing from the past 5-6 years or so working with companies on real projects (and real failures). It contains things I have not seen in other places – writing readable, maintainable and trustworthy tests, as well...

Watch previous videos: Test Review #1 – NerdDinner Test Review #2 – ASP.NET MVC     In this video I go over the tests for Microsoft Unity Application Block. Overall the quality of the tests in Unity is pretty good! I could certainly recommend that people look at them as examples of a bunch of tests against a framework, which are mostly very readable and maintainable. Things I walk through: Using [Ignore] exploration testing magic numbers and strings un-needed asserts Stub hard coded behavior handling config files in tests Asserts hidden in a utility method more naming conventions Separating integration tests “smart” code that is less readable Meaningless “isNotNull” tests cleaner ways of expecting exceptions Read More...