Sarah Taraporewalla’s Technical Ramblings

I had a very interesting discussion with Jen Smith today about the differences in approach to faking objects during testing. As a result, I am finally putting down my thoughts on the matter.
Canned Objects
Canned objects are fantastic to use in situations where you want an object to respond with a predefined value or you don’t [...]

The question a lot of people (especially software architects) ask when adopting TDD is how does Architecture fit in the whole Test Driven Design paradigm.
Traditionally, any new functionality is vetted by a software architect who completely designs it (on paper) and sometimes adds the foundation to the code base. The developers in the team then [...]

This is part of a conversation I had this week with my pair (in the conversation, I am A and he is B) as we were working on a new story. He, like many others, has been trying to do TDD but it wasn’t until we had this conversation that he began to understand what [...]

I have been helping my current client introduce TDD, and in doing so explaining principles such as single-responsibility, encapsulation and intention revealing names. As I said in my previous post Test first does not magically improve the code base, but you need to concentrate on writing good tests to help you drive out good design. [...]

Those starting out on their XP or Agile journey often hear supposedly enlightening phrases touted by those in the know like “TDD will lead you to better, nicely encapsulated, decoupled code” which leaves them scratching their heads. They are scratching their heads because they understand the benefits of adopting these practices, but they can’t see [...]

An annoying part of writing a test is the amount of setup an object can need in order to use it within the test. 

public void ShouldCalculateVolume()
{
Box box = new Box();
box.Type = Cardboard;
box.Width = 10;
box.Height = 20;
box.Depth = 40;
Assert.AreEqual(8000, box.Volume)
}

However, there is a solution: builders. Builders help by allowing you to only setup the data relevant [...]

The comments on my last post about acceptance tests have made me think a little more about testing, particularly the value in specifically declaring the type of testing you are doing. 
Unit testing is a method of testing that verifies the individual units of source code are working properly
http://en.wikipedia.org/wiki/Unit_testing
 
Integration testing…is the phase of software testing in [...]

There – I said it. Heresy. But, I am yet to be sold on their value.
Before I continue, I should describe my observations of acceptance testing. From what I’ve seen, acceptance tests are created as assurance that a story is complete. They are a layer above unit, integration and persistence tests. Their assertions are based around acceptance [...]

Often, I see tests like the following:

public void SuccessulUpdateOfCarDeatilsShouldReturnSuccessResponse()
{
CarController controller = new CarController()
controller.UpdateCarDetails(0, string.Empty, string.Empty, string.Empty)
Assert.AreEqual(200, controller.Response)
}

This conveys to me two things about the author of the test:

They treat tests as second-class citizens
They have no respect for me, the unknown reader of the test

Let me explain. I could be viewing these tests for a variety [...]

Around Thoughtworks, there is much discussion about test strategies. The arguments range from setup vs inline; named vs anonymous; mocks vs stubs; high level vs unit level, and everyone has their own preferred techniques. While a lot of people talk about the virtues of either side, I wanted to talk about using test names wisely.
I [...]