In version 5.2 we're introducing a new set of API which for VB developers. Let's start with...

Why?

We already have VB support in Isolator. It's already there in full glory in Natural and Reflective mocks. The difference starts with AAA. Because the C# AAA API is based on Lambda Expressions, VB users can use only part of it. I won't go into details, but it's because of the VB support for Function(Of T) but not for Action(Of T). So we could wait for the next VB version (in VS2010) to come out. We decided not to wait.

We see Arrange-Act-Assert as the way to go. We're adding features to the C# API all the time, and we don't want to see VB developers left behind. Truth is, we see a big opportunity in the VB market, to help introduce VB developers to unit testing and isolation with Isolator.

So here comes the new VB API. It is also AAA in nature. There's a new assembly called Typemock.Isolator.VisualBasic that you reference from your VB test project, and presto! you have all the features of our AAA C# API in VB. Obviously going forward all the neat features going into both versions.

Here's an example of a the new API:

<TestMethod()> Public Sub FakeVerification_HappenedWithExactArguments()
        ' Create and set up a fake object
        Dim fakeProduct As Product = FakeInstance(Of Product)()

        ' Fake a return value
        Using TheseCalls.WillReturn(100.0F)
            fakeProduct.CalculatePrice(0)
            Dim dummy As Single = fakeProduct.Price
        End Using

        ' Perform a calculation on the product
        Dim handler As New ProductHandler()
        handler.CalculateProductsYearlyNetWorth(fakeProduct, 100, 4000)

        ' Verify that CalculatePrice() was called during the calculation with the correct number of items
        Using AssertCalls.HappenedWithExactArguments
            fakeProduct.CalculatePrice(100)
        End Using
End Sub

The C# developers can identify the FakeInstance (which is similar to Fake.Instance). The WillReturn also seems familiar but it comes in a Using block. The equivalent of Isolator.Verify is AssertCalls, which is also used in a Using block. A nice VB API feature is that with the Using block you can have multiple functions and properties returning the same value, or use the AssertCalls block for multiple functions. (for C# developers who finally feel VB envy - you can reference this assembly and use it as well).

One difference to note in the VB version of WillReturn. It is not type-safe, meaning, the compiler allows you to write instead of the Single value 100.0F, let's say a string "100.0F", although CalculatePrice returns a Single. Isolator will find this at runtime, and will throw an exception.

Stay tuned. There's more to come.

In his blog Derik Whittaker wrote about a recent experience he had while teaching developers how to write unit tests using Isolation framework.

The post titled "Teaching someone to test using an Isolation Framework" describes how someone can use pair programming in order to help fellow developer to learn how to approach the subject of writing isolated unit tests.

I found the tips in the post extremely useful when teaching a new subject to a fellow co-worker:

• Slowdown, slowdown, slowdown
• Make NO assumptions, teach as if they know nothing
• Have them drive
• Provide examples both with and without the Isolation framework
• Don't let them skate by
• Turn off any coding tools such as ReSharper (or the likes) and do NOT use shortcuts

I especially liked the usage of a tool called Keyboard Jedi (written by Roy) so that your pair won't get lost when you start using keyboard shortcuts.

Go read it now

Derik Whittaker posted on "Teaching someone to test using an Isolation Framework". I wrote about this experience before, and I like the points Derik describes during his teaching session.

Derik has chosen to go with Rhino, but maybe going with Isolator would help speed things up next time:)

In my last post, I detailed the process of writing the first unit-test. So now you got your fingers dirty, and you're confident. Now you want to start unit-testing in a more managed, process-oriented way. How do you do it?

Let's say, for example, you have Team System in place, and you use it for source control and tracking work items. Obviously, you can do much more with Team System, but let's start with the basics. You've tasted enough unit-testing to feel that everyone can benefit from them. Where would you start?

Here are my thoughts. This is what I would consider the essential setup to start with.

1. Check in whatever tests you already have, and start checking in any new test code. You don't want to lose what you already have. Even if you don't have a continuous integration system in place (see the next step), you can run the tests manually on your (or any) machine anytime.
2. Use a continuous build system. In Team System it's Team Build, or you can use CruiseControl.Net, TeamCity, or any another tool. Whenever someone checks in code, the build starts automatically and reports success/failure. Without running the tests, it would just give a compilation status report, which is a good starting point. The entire build process, from beginning to end should be automatic, and should not have anyone intervening, or fixing just one thing to work. Think of it as a pulse of the project. If the build fails, fix it pronto. Don't let the poor team lose it's pulse.
3. Add to the build script (or integration script) running of tests. Any automated test should run within the build cycle. The build report should report the results of the tests.
4. Make a habit of looking at the test report. If the build fails because of test failure, consider it good feedback. It motivates you to do something - fix the test, change it, delete it, or even ignore it or leave it there. You need to be aware of the test results. From there you can improve.

Once you have this setup, you can now start improving other stuff, like say, prioritizing or tracking your progress. In the next posts, I'll discuss what to track, and how to manage your unit-tests within a process.

There are a lot of good tutorials on how to start Test driven development (TDD) that help understanding how he can start using this software development methodology. Unfortunately most of those tutorials explain how to write simple unit test to test some imaginary class and do not explain using mocking frameworks as part of the tutorial.

Many newcomers to the Test Driven development world do not learn about mocking framework mainly because of the misperception that mocking is difficult to use and an unnecessary complication of tests.

Hopefully in the following post I would be able to dispel this notion.

The background story

You are a developer working as part of a team developing a new CRM system.

Today you are tasked with adding new functionality to an Order object - When a ProductId is added to a newly created Order the TotalPrice property of that order shall be equal to the product's Price.

The only problem is that the developer that is responsible of the Product object didn't finish writing the data access code yet.

Note that even if the product object was fully implemented it's we don't want to create a new database every time we run our tests.

So what is TDD?

If you haven't heard of TDD before I suggest you go and read the definition of Test Driven Development on Wikipedia:

Test-driven development (TDD) is a software development technique that uses short development iterations based on pre-written test cases that define desired improvements or new functions. Each iteration produces code necessary to pass that iteration's tests. Finally, the programmer or team refactors the code to accommodate changes. A key TDD concept is that preparing tests before coding facilitates rapid feedback changes. Note that test-driven development is a software design method, not merely a method of testing.

Test-Driven Development is related to the test-first programming concepts of Extreme Programming, begun in 1999,[1] but more recently is creating more general interest in its own right.[2]

Programmers also apply the concept to improving and debugging legacy code developed with older techniques.[3]

TDD can be summarized as a set of the following actions:

1. Write a test that fail
2. Write code to make the test pass
3. Make sure that all of the previous tests still pass
4. Refactor your code
5. Repeat (if necessary)

[Image from Yet Another Language Geek blog - Musings on Software Testing]

How to start - writing the test

In order to start TDD we'll need the following:

• Editor to write your code - most windows developer prefer to use Visual Studio but feel free to use whichever editor/IDE you usually use
• Unit testing framework - you can go and download NUnit it's free and easy to use.
• For the purpose of this tutorial you will also need Typemock Isolator - you can get a 30 day evaluation copy from our download page.

Create a new class library (dll) project and add a reference to nunit.framework.dll.

And now we can write our first test:

   1:  [TestFixture]    

   2:  public class OrderTests    

   3:  {    

   4:      [Test]     

   5:      public void AddProduct_AddOneProductToOrder_OrderTotalCostEqualProductPrice()    

   6:      {    

   7:          var productPrice = 15.00;        

   8:          var order = new Order();    

   9:          order.AddProduct("product1");

  10:          Assert.AreEqual(productPrice, order.TotalCost);

  11:      }    

  12:   }       

Running the test above cause an exception to be thrown from line 9. because product data access is not implement yet running Product.Retrive throws an unimplemented exception.

Now we have to decide what to do:

1. Complain that the Product class was not finished yet.
   


2. Use Fake product instead.
   

Faking It - how to write your first mocked object

• Download Typemock Isolator and install it on your computer.
  


• Add references to Typemock.dll & Typemock.ArrageActAssert.dll
  


• read below
  

In this test we want to Fake the static call Product.Retrive so that it would return a product. Using Isolate.WhenCalled we can define that behavior

   1:  [Test]     

   2:  public void AddProduct_AddOneProductToOrder_OrderTotalCostEqualProductPrice()    

   3:  {    

   4:      var productPrice = 15.00;var p = new Product("product1");    

   5:          

   6:      var p = new Product("product1"); 

   7:      p.Price = productPrice;   

   8:      Isolate.WhenCalled(() => Product.Retrieve(string.Empty)).WillReturn(p);    

   9:       

  10:      var order = new Order();    

  11:       

  12:      order.AddProduct("product1");    

  13:          

  14:      Assert.AreEqual(productPrice, order.TotalCost); 

  15:   }

On lines 6-8 we create a new Product and tell Isolator to return it when Retrieve method being called.
Back to TDDWhen running the test another exception is thrown - because we haven't implemented AddProduct functionality yet.

So we write a simple implementation to fix our test:

   1:  public class Order  

   2:  {  

   3:      public double TotalCost { get; set; }  

   4:      public void AddProduct(string productId)

   5:      {  

   6:          var product = Product.Retrieve(productId);

   7:          TotalCost += product.Price;  

   8:      }  

   9:  }

Note that AddProduct currently only increase the amount of the order's total cost, because TDD means that you write only the code required to pass the test. In the future we'll add tests to check that the product was added to our Order as well.

Now our test finally pass. Congratulation not only do you know how to write unit tests you have witnesses faking of objects as well.

Not too hard now is it?

This week I met with a prospect, who, low and behold, is a developer. And we jumped into the code. That means that I made him choose a piece of code he wanted to test, and we wrote a unit test for it, using Isolator.

Sounds easy. It took an hour and a half.

This post is about the steps we went through when starting to unit test. It is an example for everyone brave enough to learn how to start unit testing, on his existing code-base. We'll start with a pre-requisite: have a test framework in place. We had to install the MS unit testing tools as part of VS, because it wasn't installed.

1. Pick what to test.

This took about 15 minutes. I emphasize that I want to test logic, meaning ifs/switches and such. Start from there, and build tests around that piece of code. As the first test, I want to test a simple if statement. What we chose is an IF surrounded by a for-each loop.

2. Pick a scenario.

Once you selected a simple enough code to test, it's easy to pick a scenario. If not, go back to step 1, and select simple code that you can think of a scenario for.

3. Write an empty test, naming it after the scenario you are about to test.

This is crucial, especially when pairing. And if not. If at least one of you is inexperienced in writing tests it's easy to go off on a tangent, and naming helps focus. We use this pattern for naming tests:

METHODNAME_WHEN_EXPECTEDRESULT

Where WHEN is the scenario's initial state, which drives it. and EXPECTEDRESULT is what we are going to assert. We usually have one test class per tested class, so there's no need to use the class' name. Make it readable, so everyone who reads it understand what you are testing. Get someone to review the name, or pair with someone. Did I say this is crucial?

4. Write the test's body without any faking code. It MUST assert something.

When we wrote the test, we just invoked the method. If it runs, it's ok, since the test didn't crash, right?

Wrong!

Write an assertion. Even a simple one, like IsNotNull. A failing test that fails because of the assertion. Of course initially the test crashed before getting to the assertion, but after adding some faking code, it didn't and we didn't know if the test really passed. So add an assertion.

5. Run the test.

At this point, I knew it would fail, but I wanted feedback. It crashed somewhere in the database access in EntLib (MS Enterprise libraries). Which led us immediately to the next point:

6. Think. Decide what you want to fake. Then think again. Be sure.

I could fake database calls in EntLib. But do I really want to do it? Why not fake the DAL (Data access layer) objects? They encapsulate more calls, and I'll write less faking code. What helped here is stepping through the code with the debugger, seeing all the method calls, and who's calling who. Isolate where it makes sense.

7. Write the faking code. Understand what you did. Repeat

Adding faking code is easy with Isolator. That doesn't mean it's what you actually meant to happen. So if you come by a type called XYZ collection, make sure it implements IEnumerable before using the collection APIs. After it works, and you build a return value, go back to the tested code. Implement enough faking code that satisfies the tested code, and the scenario. Does the returned collection need to be filled with objects? Initialized objects? Add all the setup code to the test, and make sure you understand what you're doing. Iterate through all the dependencies, and add faking code.

8. Run the test. Recheck if fails. Make corrections.

After completing the entire fake setup, we realized the assertion should be negated. Stupid isn't it? But it just goes to show that after going through the first steps, there's still some thinking to do.

9. The test passes.

Grab a cup of coffee, you earned it. Then test another scenario.

Unit test coverage of developed code can make sure that functionality won't change during refactoring of legacy code, new feature development and more.

Although it might help It is not necessary to use Test Driven Development (TDD) all that is needed is to write unit tests before the actual work (i.e before a major bug fix).

Today I found another use of unit tests - code parallelization.

In his blog - Rick Minerich writes on how a developer can parallelize existing code to improve its performance.

Rick uses a methodology called RASP:

1. Review: Review code to determine if it is a good candidate for parallelization.
2. Anchor: Create a unit test fixture to ensure that the behavior of the to be parallelized code does not change.
3. Separate: Ensure that the to be parallelized code has no shared memory constraints.
4. Parallelize: Minimally refactor for parallelization while leveraging an existing API to do the heavy lifting.

As you can tell from the steps above an important part of the process is creating unit tests to make sure that the existing functionality won't change during the process.

Of course users of TDD do not need to write tests because they already have them written as part of the development process.

Another place where unit tests are a major part of creating high quality code.

Mads Nissen had an issue with Typemock Isolator and Gallio integration
He was kind enough to let us work with him and solve the problem.
Thanks Mads!

In his blog post mentioned above he says:
"First I added most of the TypeMock 5.1 binaries to my buildtools svn repository (no, didn't bother to investigate which files I actually HAD to include - TypeMock Team: It would be nice to have this documented in order to create the smallest possible footprint for this scenario)."

Well Mads is right and here is the list:

• TypeMock.dll (Should be in the GAC)
• Configuration.dll (Should be in the GAC)
• MockWeaver.dll
• ProfileLinker.dll
• namespaces.dat
• typemockconfig.xml
• TypeMock.Configuration.exe
• Typemock.ArrangeActAssert.dll

If you are using MSBuild or NAnt:

• TypeMock.MSBuild.dll
• TypeMock.NAntBuild.dll

A note about the MockWeaver.dll and the ProfileLinker.dll:
These are native assemblies that has specific versions for 32 and 64 bit.
If you are running on 64 bit OS create x86 and x64 directories just like they are in the Isolator installation.
Both MockWeaver.dll and the ProfileLinker.dll needs to be registered via regsvr32.exe.

Providing customer support is a top priority for us, be it through our support mailbox, online forums, phone or direct email. We actively try to make our support services available, responsive and of the highest quality. 
So what happened?
However, our efforts hit a road bump in the last couple of weeks, when we had an internal problem with one of our smtp services. This mail service is in charge of relaying mail going out of our support system to our customers, and unknown to us it stopped working. This caused our support emails - including follow up on issues, checking up that problems have been solved and sending patches - did not go out.
Finding out was hardTurns out this can go on for a while before finding out. We were churning along, providing support for the issues that kept coming in, sending out emails to customers and changing the ticket status to 'waiting', all the time oblivious to the problem. Eventually, we had a day where a support case email was cc'd to another team member for follow up, and when he complained he didn't get it we found out about the problem. Upon further investigation the faulty mail service was identified and fixed. It also turned out we had no information about how long we were offline.
Trying to make up for lost timeWe immediately went back to our email archive and looked for the last customer acknoledgement of a support email. This was a couple of weeks in the past so we went ahead and re-sent all the emails we were trying to get out in these weeks. 
So what did we learn?Several things, really. First, that a lull in support cases can be a sign the end of the year is coming and things are slowing down, but it can also be a sign something is not working well. Another thing is that we need to harden our IT systems and get an early indication of a system failure before it impacts our customers. We already set out to implement a self test that will run daily to make sure our support system is working as it should. 
To summarize, I apologize for all of you who didn't get the support you deserve during that time; if you feel we might have missed your case, or if it's otherwise urgent, please write me at doron@typemock.com, and I promise you'll get an answer fast.

Isolator Expert Soon Hui has written a post in his blog explaining how to test SMTP client using AAA fakes.

The post shows how to unit test a SMTP client without needing to set up a server and without dependency injection.

You can read it at: Unit Testing SmtpClient class with TypeMock AAA Syntax

Since launching the AAA API for Typemock Isolator last summer, we have put much care and consideration into making sure we are doing things right this time around. There are many considerations we take into account before performing any addition to this API, including

• Fluency and natural language readability - in my opinion readable tests = maintainable tests = effective tests.
• Usability and cognition - avoid too many choices on screen, avoid forcing the user to remember a completing statement if possible.
• Error prevention - any usage mistake is probably our own bug. We analyze those to understand where we could have helped the user avoid the mistake in the first place.
• Conciseness - use one statement instead of two if it doesn't involve making (too many) hidden assumptions about test behavior.

The AAA API has gone a long way since its launch with the addition of static method support, non-public method support, duck-type swapping and more. We painstakingly consider the resulting API changes in any such addition to maintain the above API quality criteria.
We are looking to add many additional features to this API; some of these features are familiar from our other APIs (Natural and Reflective), and some are new. We are focused to bring the AAA API up to the capabilities of our older APIs, but make it better in usability and readability. We also have cool features in mind which we will add to it as well. 
The following features are right now on our AAA release backlog. The order and content may vary, but you can expect to see these features implemented in the near future with detailed posts for each around release time:

• Repeating and ordered method behavior
  
• Handling properties and indexers
  
• Conditional behavior
  
• Handling method overloads properly
• Faking method with dynamic behavior
  
• Faking behavior for all instances of a class
  
• Faking base class behavior
  
• Faking event handling
  

Note that this list is partial and does not include other development plans we have, such as improved Visual Basic isolation support,  cleaning up and simplifying error messages, better development environment integration and more. As an agile development team we are constantly adjusting and shifting plans. Think we left something out? Want to see another feature I did not mention? We are open to anything - just post a comment!

Mark Needham posted on what makes a good unit test. Very good read.

I agree with Mark about the DRY (Don't Repeat Yourself) principal in tests. This is somewhat controversial, so naturally I've got something to say.

DRY comes as a solution for maintainability. If code is not duplicated, and sits in one place, then maintaining the code is easier and costs less. No argument here.

In tests, there something else to consider. I am a strong believer in test as a spec. And readability is needed for specs. So this is where test maintainability may clash with readability. I side with readability every time. That's why I prefer repeating the setup code in the test than putting the common code in a setup method.

Where do you stand on this issue?

The SharePoint team of Microsoft Consulting Services Norway Information Worker posted guidance on how to start working with Isolator with SharePoint. It gives you points, best practices, and recommendations. And it's only part 1 - can't wait for the second one.

In one word: Awesome.

In five words: we should have written this.

As for the correct comparison between APIs -  we are now working on filling in the not supported features in the AAA syntax. For example, we're now working on Repeats. We'll get there.

Great job guys!

I noticed that two features that came out in version 5.1.1 of Typemock Isolator can cause confusion.
The features are Duck Typing and Swapping collections.

Lets look at their method signature:
For duck typing it is:
Isolate.Swap.CallsOn(object toSwap).WithCallsTo(object swapped);
For swapping collections it is:
Isolate.WhenCalled(Func<T> func).WillReturnCollectionValuesOf(IEnumerable collection)

Notice that when you use Duck Typing the CallsOn method takes an object as an argument while WhenCalled takes lambda expression as an argument.
The difference is that when you use Isolate.Swap.CallsOn(object toSwap) ...
the method or chain of methods inside CallsOn will be evaluated (not faked).
While the lambda expression inside WhenCalled method is faked.

For example in the code below:
Isolate.Swap.CallsOn(a.b.ReturnSomeObject()).WithCallsTo(myFakeObject);
a.b.ReturnSomeObject() will be called and the object that is returned from the chain will be swapped with myFakeObject.

On the other hand if you call:
Isolate.WhenCalled(()=> a.b.ReturnSomeObject()).WillReturnCollectionValuesOf( new string [] {"John", "Paul"} );
That's like saying to the Isolator "when the chain a.b.ReturnSomeObject() is called just fake it and return the string array {"John", "Paul"}"

Happy swapping!

We would like to thank everyone that participated in the launch of Isolator for SharePoint.
We have already received over 50 posts about this launch, and we sent the free license to the first 50 bloggers who posted about this.

If you would like to evaluate our tool for unit testing Microsoft SharePoint applications, and you were not in the first 50 to blog about this, you can always download it and evaluate it during the free trial period.

We would be delighted to hear your feedback about Isolator in our forums and blog, also please feel free to review it on your blog.

Below you can see the list of bloggers who won a free license:

Tim Wheeler
Matthew Frank
Harish Mathanan
Glenn Wiley
Bill Craun
Ran Davidovitz
Kanwal Khipple
Matt Smith
Aaron Powell
Philip Kirkham
Molnar Agnes
Roger Noble
Alpesh Nakar
alberto
Paresh
Michael Nemtsev
Keith Dahlby
Matthew Bremer
Patrick Yong
Jeremy Thake
Robin Meure
Spencer Harbar
Rune Rystad
Fernando Felman
Magnus Johansson
The Black Knight (Per Jakobsen)
Daniel McPherson zevenseas
Brian Farnhill
Tom Pester
Ryan Riley
Nadege DEROUSSEN
Chris Jacob
Baes, Christiaan
Tony Rasa
Ricardo Peres
Dragan Panjkov
Stein, Christian
sezai komur
Bastien PROT
Steve Pietrek
Alexander James
Tyler MacLeod
Adrian Bogdan Mocanu
Scott Hoag
Hermans, S.J. (Serve)
Nguyen Huu Hoa
Daniel Gonzalez Garcia
Grant Palin
Vochten, Thomas
Dostalek, Kevin

The Typemock team

We would like to thank everyone that participated in the launch of Isolator for SharePoint.

We have already received over 50 posts about this launch, and in the upcoming week we will send the free license to the 50 first bloggers who posted about this.

If you would like to evaluate our tool for unit testing Microsoft SharePoint applications, and you were not in the first 50 to blog about this, you can always download it and evaluate it during the free trial period.

We would be delighted to hear your feedback about Isolator in our forums and blog, also please feel free to review it on your blog.

Below you can see the list of bloggers who won a free license:

Tim Wheeler
Matthew Frank
Harish Mathanan
Glenn Wiley
Bill Craun
Ran Davidovitz
Kanwal Khipple
Matt Smith
Aaron Powell
Philip Kirkham
Molnar Agnes
Roger Noble
Alpesh Nakar
alberto
Paresh
Michael Nemtsev
Keith Dahlby
Matthew Bremer
Patrick Yong
Jeremy Thake
Robin Meure
Spencer Harbar
Rune Rystad
Fernando Felman
Magnus Johansson
The Black Knight (Per Jakobsen)
Daniel McPherson zevenseas
Brian Farnhill
Tom Pester
Ryan Riley
Nadege DEROUSSEN
Chris Jacob
Baes, Christiaan
Tony Rasa
Ricardo Peres
Dragan Panjkov
Stein, Christian
sezai komur
Bastien PROT
Steve Pietrek
Alexander James
Tyler MacLeod
Adrian Bogdan Mocanu
Scott Hoag
Hermans, S.J. (Serve)
Nguyen Huu Hoa
Daniel Gonzalez Garcia
Grant Palin
Vochten, Thomas
Dostalek, Kevin

The Typemock team

Sometimes it's a short post that has lots of great info.

Tim Ottinger wrote about Unit Test Ice Breakers - you have legacy code and you have the motivation to write unit tests. You just don't know where to start. Here's what Tim suggests:

• Start by testing you can instantiating the class.
• Test that you can call the function at all.
• Pick the easiest bit of functionality.
• Write an empty function name and assertion first.
• Write the function call as you would like it to appear.
• Refactor the existing tests.
• Pick the most interesting bit of functionality.
• Switch partners.
• Read the code for obvious flaws.
• Rerun the AT

We all know that using TDD is the best way to reduce debugging time. We also know that if you have a bug, and you have tests for your system, it's easier to fix the bug. By either writing a short needed test or debugging a simple test (rather than the entire system), we counter the programmer productivity nemesis - the debugger.

It's interesting to think about it this way - our main tool is the one that bogs us down when we want to get productive. I guess it's another case of how you use the tool.

Kent Beck, of XP (extreme programming) fame, posted an article about an innovative way to find bugs. You can guess - it's starts with a test. The test fails and reproduces the bug. Now, in most cases, we would start stepping into our code with the debugger, opening enough watch windows as we can, until something catches our eye - thinking "this data should be different" or "this line shouldn't be here". Because I'm lazy, my punishment is to repeat this, since I tend to jump between big pieces of code. So finally, after some kind of "binary search" debugging, I get to the problematic line of code.

Sounds familiar?

Kent suggests this repetitive process, that does not involve the debugger:

1. Inline a non-working method in the test.
2. Place a (failing) assertion earlier in the test than the existing assertions.
3. Prune away parts of the test that are no longer relevant.
4. Repeat.

I encourage you to read the entire example. The crux is: What I do in my brain during my "binary search" debugging, he's doing with a text editor. And methodically, I might say. What you are left with is a short concise test that represents the bug, with a very clear way to see the offending line. No debugging needed, just editing. It's not a substitution for the original failing test, it's an addition.

In his post, Kent says the most time he spent was on the editing. Apart from moving code, it also requires making private methods public. But with tools like Resharper or Refactor! this may could be a breeze. (just need to revert the code afterwards). Right tool for the job. Again.

Now for the Isolator angle: Without pruning, at the test level, you can write at least one type of assertion like this: with Verify.WasCalled and family. What's really missing today is an API like this:

Isolate.Verify.WasCalledWithAnyArguments(()=> form.IsDirty).AndReturned(true);

With these types of assertions, you do not need to edit your code, but place assertions in your test (like check points). You run your tests, don't debug, and narrow the search until you find the offending line.

What do you think? Would this API be useful for you? Is Kent's way the new TDD? And are we ever going to find out what Jack Bauer does after-hours?

[Via ObjectMentor, Uncle Bob]

 

I am happy to announce we are launching a new support venue for Typemock users. Have a quick question? want to go over a problem with one of our developers? we are now readily available on our new live help chat - if you see the image on the right and want to ask a question, just click and voila! - you are in a chat room with a developer. We are operating this service during GMT business hours, and everyone is invited to join. When we are offline (probably because we are asleep or with our families...) you are welcome to our support forums, or you can write us an email.

You can find links to our live help system on our web site, on the Products and Learn page - go ahead and give it a try.

[Via Boris Gloger]

MethodsAndTools.com, which I know from their excellent newsletter, have published a poll about the adoption of unit testing. It seems that developers are adopting it but very slowly. Read the results here.

What caught my eye is something near and dear to me – people who already were performing unit tests have switched to the TDD approach. That was they way with me.

So what do you think. Do we still have a long way ahead of us?