Home » 2015 » February

Excuses For Not Testing

ppl-kid-044As I started my own journey into unit testing, I slowly began to realize that it was really easy to come up with reasons to NOT test my code as I was writing it, even once I understood what that was supposed to look like. The reason I think most programmers don’t unit test code, once they understand what it is they are supposed to be doing is that they don’t feel like they have permission.

To this I also answer, “How much permission do you need?”

Continue reading “Excuses For Not Testing”

Being Agile Is About The Journey…

… Not The Destination

BeingAgileThis post first started as I was discussing my post “You Aren’t Doing Scrum If …” with a friend who had read the post and was worried that I might not fit in an organization that wasn’t doing all of Scrum.  I’ve since had other conversations and as I’ve reflected on the topic, I still stand by my original post, because there are some fundamental properties of Scrum that you have to implement in order to follow that methodology.  This is why I called the post “You Aren’t Doing Scrum If …” and not “You Aren’t Doing Agile If …”

Agile isn’t Scrum

But Agile is different.  Agile isn’t a process. Agile is a mindset.

So you can call yourself “Agile” without necessarily implementing any particular methodology because “Agile” isn’t about process.  Agile is about the collective state of mind of the team.  The organization as a whole.  Being Agile means that you are open to change.  That you embrace change.  Agile is about being flexible.  About knowing that you don’t know and that you don’t know what you don’t know.  Agile is about adapting.  Ultimately, it is about finding ways of being more productive.

In fact, you could implement scrum precisely, which I doubt anyone really does, and not be Agile.

Sacred Cows

In fact, my experience has been that as I try to move an organization along the sliding scale of  being more productive, I will, eventually, find a point of resistance.  The sacred cow of their process.  You can change whatever else you want, and yes, everything else you’ve suggested that we change has proven itself to be a better, more productive, less error prone way of doing what we do.  But, you can’t change our sacred cow. And so far every organization I’ve been in has some sacred cow that we either have to kill or we don’t progress further into being agile.

And so we end up hearing comments from people in the industry like, “I don’t think I’ve been in any organization that has been TOTALLY ‘Agile.’” because every organization eventually runs up against some sacred cow on their road toward being agile.

Leadership Needs To Be Agile

I know of another guy in the industry that postulates that the reason organizations fail as they try to implement agile is because agile is being forced on the organization.  That we need to create an environment where people have opted in to agile.  And to a certain extent, I think he’s right.  But, and I think this is a HUGE but, I think the larger problem is that the leadership has not embraced being agile and so you end up with developers trying to BE agile while the leadership is trying to be predictive.  Funny thing I’ve noticed about most employees, they’ll pretty much do whatever they think will keep the paychecks flowing.  So I don’t think we need opt-in at the worker bee level so much as we need opt-in at the leadership level.  Although I have seen resistance at both levels.

Individuals Need To Be Agile

Finally, while your organization may not be agile at all. It may not do Scrum, or Kanban.  It may resist all attempts to move in that direction.  This is not excuse for you to not be agile. You should ask yourself periodically, “What can I do that might be more productive than what I am currently doing?”  Because an organization can only be as agile as the people working in that organization and sometimes, all it really takes to move an organization closer to being agile is one individual who is willing to do what he or she does just a little more toward agile than they currently are.

What sacred cows have you run into?  What are you doing to be more agile as an individual?  Leave a comment below.

Links About Being Agile

NUnit Test Code Structure

UnitTestStructure

There are two basic ways to structure the code you will be working on to Unit test the code in your main application using NUnit.  Arrange/Act/Assert (AAA) is what I refer to as the “Classic” method.  It has been around for as long as I’ve known about unit testing. The second method is the Given/When/Then (GWT) structure.

While both methods get the job done and both methods essentially help you structure your test, I think that the Given/When/Then structure helps us think about what we are trying to test from a more functional perspective.  Arrange/Act/Assert is more of a code based approach.

Since, in the end, what we care about is the functionality that we have coded.  I prefer Given/When/Then.  I also think GWT is better suited to Test Driven Development since in Test Driven Development, we are already in the mindset of “What is it that I’m trying to accomplish?”  And not, “What did I do and how do I test it?”

Arrange/Act/Assert

The classic method of arranging our NUnit test code conforms to the “Arrange/Act/Assert” pattern.  Using this pattern, we setup our code so that it is in the state we need it to be to perform the test.  Then we perform some distinct action on the code.  This action should exercise one and only one feature.  And then, finally we assert that the action we performed resulted in some expectation being fulfilled.

What?  Huh?

So, maybe some code will help.

Let’s assume that we have a class, Calculator, that has a method, Add:

public class Calculator
{
    public int Add(int a, int b)
    {
        return a + b;
    }
}

To test this class, we create another class in our test project that we will name CalculatorTest.  Well, what do we want to test in our Calculator class?  We want to test that when we add two numbers together, the proper sum comes back.  So, we’ll need a test method.  It is customary to name our methods what we are trying to test for, so we will call our test method AddShouldReturnSumOfTwoNumbers().

Following the Arrange/Act/Assert pattern, the first part of our method will create the Calculator object, then we will call the Add method, passing it two numbers, and then we will Assert that the proper result was returned.

[TestFixture]
public class CalculatorTest
{
    [Test]
    public void AddShouldReturnSumOfTwoNumbers()
    {
        // Arrange
        var sut = new Calculator();

        // Act
        var returnValue = sut.Add(3, 7);

        // Assert
        Assert.That(returnValue, Is.EqualTo(10));
    }
}

Given/When/Then

An alternate way of thinking about test is by using the Given/When/Then construct.  It essentially arranges the code in the same way, but I think it helps you think about what it is you are trying to test better.  Arrange/Act/Assert (aka AAA) tends to have you think about your code from a programmer’s perspective.  “This is what my code does.”  The Give/When/Then method thinks about the problem more from a requirements perspective.  At the end of the day what is important is that you have test around your code, so I’m not going to spend a lot of time arguing that one way is particularly better than the other.  But GWT is what I use. Since this is my post, that’s what we are going to use for the remainder of this book.

So going back to our Calculator example, what would GWT look like?

[TestFixture]
public class CalculatorTest
{
    [Test]
    public void AddShouldReturnSumOfTwoNumbers()
    {
        // Given that we have a calculator
        var sut = new Calculator();

        // When I add 3 and 7 together
        var returnValue = sut.Add(3, 7);

        // Then the result should be 10
        Assert.That(returnValue, Is.EqualTo(10));
    }
}

See, it’s all the same stuff, so whatever helps you think about what you are testing is what you should use.