Johnny Halife’s Blog

While attending some CMMi courses that we held at Southworks, and reading some papers about re-work written by Watt Humphrey and the CMU-SEI crew, I started thinking about how to avoid rework and what do I do to avoid re work while coding.

I realized while asking myself a couple of questions and analyzing the code review results for the reviews I conducted that most of the people make the code work, check the code in and then start caring about the quality of that code. For example most of the people check in code that doesn’t meet the code standards and then they do another check in in order to fix those.

I came up with 10 do’s and don’ts while coding that helped me understand how to avoid rework and ensure the health of our deliverables on every check in.

10 Do’s and Dont’s to avoid quality rework

These do’s and don’ts aren’t a silver bullet but they may help you as a strong starting point for avoiding rework on quality related subjects.

Do check-in often

As Alex always says Software Development is a team sport played by talented individuals. While you keep your code in your local machine you’re also putting a barrier between your work and the rest of the world’s work. Doing check in often helps you on integration, avoiding conflicts and even better gives the team visibility on where are you in terms of what you committed to do. In the other hand if you don’t commit often, be prepared to spend half a day fixing the code to avoid conflicts.

Do run StyleCop each time you modify a source code file

Code Standards are something big to be treated on another post by itself but as summary I’ll say that in Southworks we chose the working software over the comprehensive documentation as the Agile Manifesto states.

We have chosen to use Microsoft’s StyleCop to validate our code standards. Most of the code that we write often goes public, and it’s important to demonstrate that we follow a single line of thinking and the code has signature that differentiates it  from others code but also that the code is written in the same way by all the developers on the company.

In order to accomplish this, is as simple as doing right click on the source code file in Visual Studio and then Run Source Analysis. It won’t add an overhead to your regular coding routine but will ensure that the code is written on a consistent fashion the first time.

How to run source analysis

Do run Code Analysis prior every check in

Code Analysis (a.k.a FxCop) is the tool that validates the best practices of the Microsoft.net Framework. It’s based on the book written by Brad Abrams and Krzysztof Cwalina. The best practices described there were ported to an application known as FxCop.

Following Code Analysis guidelines ensures that our code is leveraging the Microsoft.net framework in the best way it can be done. And the same as Style Cop (a.k.a Source Analysis) it can be done by doing right click on an assembly in Visual Studio and then choosing the Run Code Analysis option from the context menu.

Again, doing this the first time is better than reworking the code and re committing to the main line twice in order to do it and then to fix it.

How to run Code Analysis.

Consider branching out code that may introduce risk to your deliverables

This is pretty obvious, sometimes you think a problem can be solved using some kind of approach that might have an impact on others work. The solution there is to branch the code out and don’t introduce the risk while you’re not sure that this will be the final solution or at least that your solution works.

Why is this? Some people might choose to keep it outside the source control but experience tell us that no source control will turn into something painful if something happens.

I’ll write another post about GIT which leverages this by having a local repository for each developer but that’s another story.

Do not forget the commit message

Look at the log above what can you tell about what’s going on on the project? If you don’t include a comment, a note, a reference to a requirement or something that states what are you committing you can get your team in trouble if you have to do any rollback or review of the requirements implementation.

It’s a 1 minute thing to say what are you committing and why are you committing, that also forces you to think what problem, requirement or commitment are you closing with that check in.

Do be polite with the Integration Server

This one is loved by my friend .jpg who is our Build Server & Tooling ranger. People often get confused with the intent of an Integration Server. The Integration Server is used to verify that there’s harmony in your repository, it’s not your tool to validate your code against. You should verify your work against it but don’t use it processor cycles to do your validation work.

Our build process is complex enough that might take at least 2 minutes to build a project, people often think that is the Integration Server responsibility to validate your process. Truth to be told, the intent of the Build Server is just to verify that there’s no integration problems and that all the code follows a standard.

Although the quick feedback is the most important part of the build server, you should have in mind that is a verification of work and it doesn’t do the validation you’re supposed to do.

Do not check in prototype quality code to your main line

I won’t go further on this one, I recommend you to read I.M Wright’s post about Prototyping that he just posted. As an spoiler I can tell you that the title gives a clear message “My experiment worked!”.

Do not check in until all tests pass

This one seems pretty obvious, I wrote a post about TDD last week and most of the people nowadays are adopting this practice. The important thing and a killing feature of TDD is that you are a click away of doing regression testing on all the code and check that nothing got broken with your changes.

Sometimes you get green on yours and then just wait to the Integration Server or another developer to complain about your work. This is the case where you should be polite not only with the integration server but also with your co-workers making sure that nothing is broken because of your changes.

NOTE: If you are running a huge solution with thousands of tests you might want to run just those hundreds tests on the impact surface of your code.

Do ad-hoc peer reviews to validate your logical thinking

Two pair eyes of eyes see better than just one. That’s the rationale behind this point. Developers (and I include myself on the subset) love to put their headphones, enter their matrix kindda world and write code as the music moves forward. But as I said on the first point Software Development is a team sport and a team that cooperates is by far more candidate to win.

Do not wait until the formal Code Review comes up to you and you have to explain what you’ve done. Just put pause on iTunes for 5 seconds, ask your nearest team member (doesn’t matter his expertise always there’s something good to learn from our peers) what does he think about your idea and that’s it. You just had a peer review.

Do be consistent and disciplined while applying the nine practices above

Now you know it, but the practice makes the master. Fasten your seatbelt and get ready to improve your personal development process. You and your team will be happy to share a principles in terms of quality so your code is nice, easy to maintain and well written.

And your team as all the famous painters will have a code signature that will distinguish yourselves from the rest of the mere mortals.

And in the end….

One thing that I’ve learnt from people that have years working on Software Quality and people that I met like Eric Brechner (Microsoft Engineering Excellence Director) is that the most important thing when talking about Software Quality is defining done. If you follow these simple steps you will be closer as a team to produce code in a standard and consistent basis while starting to define the meaning of done for code.

thanks,
~johnny

Almost form the beginning of my blog,  I started writing about Test-Driven-Development [1] [2] [3] [4] [5] that now was renamed by the Agile Gang  as Behavior Driven Design. That new name is kind of cool and fancy (Oh these agilists always looking for new adepts) but there’s a truth and a strong rationale behind what they call BBD.

I wrote this post after a long time practicing TDD, this Truths and Myths are based on my personal experience and the knowledge acquired with time. You might disagree with some, you will love others, but this post is an exercise for my self trying to dump all what I’ve learnt in these years practicing TDD.

I’ve divided the post in three parts:

• Myths. These are the things I heard while working as consultant, stuff that showed up while discussing with colleges or things that came up while discussing with friends.
• Truths. These are almost the same as above but mostly positive things that demonstrate that there’s value on applying this practice.
• My TDD Zen Garden. This are tips and tools that I used while doing TDD, they’re not mandatory or maybe part of the official practice. There I’m just sharing my personal tips and thoughts.

5 Myths about TDD/BDD

Myth 1: “Tests are for testers”

That’s my favorite one, when people don’t understand TDD or are just too lazy to write the tests they claim for the “Test is for testers”. Although the name has the word test, it doesn’t necessarily means that your testing as a tester would do it.

Myth 2: “Oh buddy, if I wrote them it’ll take me twice”

Ok some people think about writing the tests first as some kind of time consuming, useless, non-sense activity. Those that think like that are often the ones that never thought or read about Re-work  there are some great papers from Watts Humphrey and CMU-SEI Crew about this. If you had the tests to validate and verify your work, you’re one step closer to avoid rework.

Myth 3: “I’m bug free , I had 100% Code Coverage”

This might be controversial,  but after doing some deep thinking on this and listening to Scott Hanselman podcasts, I realized that 100% Code Coverage isn’t the best. Code Coverage is a negative metric, it’s about where we should focus are testing intentions based on what we’ve left uncover. As far as I researched, there’s no tool to measure code coverage by paths (this can be fairly accomplished by hand). So 100% isn’t bug free.

Myth 4: “If I apply incremental design techniques based on TDD, I end up just with a huge test method”

That’s more than a Myth, that’s a mistake, when doing TDD it’s always a matter of starting to cross tests from the lists. People often think that as the method to be tested evolves the original test evolves with it. Well, for me it’s that as you move forward you add new tests. So your fixture becomes a living, and breathing component documentation.

Myth 5: “Doing TDD covers our team from doing functional testing”

That’s something that I heard too much, in this case the Myth or assumption is not about people using it wrong, this is about misunderstanding its power. TDD as I titled this post is about letting the design to emerge by expression on a bunch of lines of code our intention for that component. Also the testability for components (the new buzz word) will help us to understand coupling (WARNING! this also might led you to over engineering).

5 Truths about TDD/BDD

Truth 1: “The TDD motivation is about writing clean code that works”

By writing the code needed just to make the test passes you are ensuring that your code fulfils just the test requirements and also that there isn’t dead code, unwanted code or other sort of code horrors.

Truth 2: “TDD outcome is a living breathing documentation for the component”

That’s one of my favorites things about Test Driven Development while you’re writing the tests your expressing the rationale behind those lines and more than that the intended use. When a new developer arrives to a project, if you can hand out a couple of fixtures for him to look at, you’ll probably get him up on speed faster than it would take if he just have to read the code.

Truth 3: “By applying TDD you end up with well factored code”

Some people think about all the decoupling stuff associated to TDD as some kind of black art or magic. Truth to be told, this principle applies painless and it’s harder to realize that you’re doing it than doing it. While you are expressing the intention and how the object should be have you’re defining almost ad-hoc what it shouldn’t do. Writing tests is determining responsibilities for components and when you define those, you’re already decoupling your objects.

Truth 4: “Doing TDD increases the motivation”

While setting micro-goals to yourself and accomplishing them you start to fell better, think of it as 3 years projects, with thousands of man hours to be invested. How do you get the fell of moving forward and don’t fall on the depression of writing code that is going nowhere. Well by simply setting a test for your code, you start to fell confident about what you’re doing and that gets you the feeling of progress as the green lights for your test cases are on.

Truth 5: “There’s no silver bullet”

This might be the most discouraging truth I’d ever written but the true doesn’t hurt. You may get all the benefits of doing TDD but you still need peer reviews, code reviews, analyze your code against formal computer science metrics of complexity and coupling, and all that stuff. I felt like you maybe be feeling when I read the same title on the Mythical Man Month, I thought about that book about the great software engineering problem solver but Mr. Brooks Jr. was pretty clear and I’m agree, there’s no silver bullet and TDD is just another great practice to use in the fight against the bug count and defect ratio.

My TDD Zen Garden

These ten tips are what I call my TDD Zen Garden, they consist in 10 things that use, think about or realized while practicing TDD for about +4 years. As I said on my last Truth (”there’s no silver bullet”) these are just practices, and I encourage you to challenge them, try to defeat and destroy them, because at that point you’ll have something to teach the rest of the world or just me, and that idea fight is really enriching.

Tip 1: “Write tiny and focused test methods that check only one aspect of your code”

If you method can’t be tested with 2 or 3 assertions, that’s code smells. The rationale behind this is to write method with less responsibilities and generate a well factored code.  A single method might take 2 or 3 test cases to test the alternative paths but a well written method will just need one to test it’s core functionality.

Tip 2: “Avoid fragile assertions on human readable text such as error or flash messages”

Try to write your tests (and your code) in order that it can be checked without doing strange things, like converting case or stuff like that. Tests are used to verify and validate that the code does what it needs to do. Think of it as an equation, don’t try to test things that might become messy.

Tip 3: “Use Code Coverage Tools”

Although all the things I said about Code Coverage percentage being a negative metric, it’s useful to know what aren’t you testing. Some people might think that when you find a line that isn’t tested what you should do is to write a test that passes over that line. My approach is a little bit different, if I find something that isn’t covered I just go and delete it. If that was something that I really need it will appear again when the time is right.

Tip 4: “Keep the test logic inside the test method”

As we discussed previously on this post, test are living and breathing documentation for the component. Do not try to refractor it in order to reuse, test methods aren’t intended to be productive code, they’re documentation and development support. Do no save space or try to reduce its numbers of lines, keep it tight, make it atomic and reduce its dependencies. That will make it more readable for people.

Tip 5: “Use mocking frameworks”

This is because mocks (pieces of code used to simulate another component) are just for testing proposes. People often fall in writing huge mocks, that often do too much and even worse they end up testing them.

Mock Frameworks, are useful because all the interaction logic stills inside the test method and as I said before the more information you give inside the test case the better. I clearly don’t have any favorite one, but MoQ and Rhino Mocks are two that I often use and mostly recommend.

Tip 6: “Don’t rely on context data for your tests results”

I often heard that some test are failing because of data that needs to be on the database isn’t there. I prefer to do the insertion and deletion and everything that needs to be done on the test method I don’t rely on existing data because that will you to a fragile assertion (See tip #2 for more info).

Tip 7: “Use Transactions instead of Tests Databases”

People often create bunches of databases to test against, I personally prefer to wrap my whole test inside a transaction. That let’s me play around without screwing up the database and even better I don’t fall on relying on Context Data for my tests. (See tip#6 for more info).

[TestMethod]
public void MyTestMethod()
{
    using(TransactionScope ts = new TransactionScope())
    {
        //write all the test logic here.
    }
}

When the using scope finishes, it will automatically rollback the transaction.

Tip 8: “Make your test cases atomic”

Do not rely on other tests to be running in order to write your test, do not make any tests dependant to other. Write you tests as if they were intended to run on isolation. This will help you troubleshoot a problem when some test fails.

Tip 9: “Do not hesitate on long tests names”

I’ll continue insisting that test are living and breathing documentation of the project, so avoid naming your tests as ShouldThrowException or something that doesn’t provide an insight of what’s going on to the reader.

[TestMethod]
public void ShouldThrowExceptionWhenInvalidCustomerNameIsPassed()
{
}

The name depicted above is an example on how I like tests method to be named.

Tip 10: “Be consistent, methodical, and patient”

It happens event to the best developers and TDD practitioners that at some point of time they go nuts and think about throwing all the fixtures and crack code as fast as they can in order to see their new creation moving. Be patient, consistent and methodical, follow always the process. Software isn’t just built and thrown away, people will have to maintain your baby so please be considered and be thoughtful and polite when your self because at some point (even the best developer) you will have to troubleshoot your code.

thanks,

~johnny

NOTE: Before you continue you need to install MS Visual Studio Team Edition for Testers.

I’ll explain how to use TDD with MS Visual Studio using a real life example. As stated in my previous post, there are a couple of steps that you can check to make sure that you are aligned with TDD.

1^st – Requirement

Consider a bag that implements the following methods IsEmpty, Pop, Push. These are the behavior considerations about the bag.

• If the bag is empty; the IsEmpty method must return true. If not it must return true.
• If you pop an item into the bag, the IsEmpty method must return false.
• If you push an item from the bag , where the item count equals to one it should return true.

2^nd – Test List

• Create a Bag and check that isEmpty is true.
• Push a single object into the Bag and check that isEmpty is false.
• Push a single object and then pop it from the bag and check that isEmpty is true

3^rd – Choose you first test

For this example we’ll use “Create a Bag and check that isEmpty is true.”.

4^th – Follow the implementation list that I

mentioned in the other post

Step 0 – Create you solution

1. Open Microsoft Visual
2. Go to File -> New -> Project
3. Select Other Project Types -> Visual Studio Solutions -> Blank Solution
4. Type TDD Example in the Name textbox.
5. Go to File -> Add -> New Project
6. Select Visual C# -> Test Projects -> Test Projects
7. Type Bag.Test in the Name textbox.

Step 1 – Write Test Code

Write the following code as your test code

[TestMethod]

public void CheckBagIsEmpty()

{

Bag myBag = new Bag();

Assert.AreEqual(true, myBag.IsEmpty);

}

Step 2 – Compile the test code

Nothing to say, just press Shift + Ctrl + B.

Step 3 – Implement enough to compile

1. Add a class to your test project called bag.
2. And write the following code

public class Bag

{

public bool IsEmpty

{

get { return false; }

}

}

Step 4 – Run the test and see it fail

1. Press Shift + Alt + X.
2. See it fails with the following error message “Assert.AreEqual failed. Expected:<True>, Actual:<False>.”

Step 5 – Implement just enough to make test pass

Replace isEmpty method with the following code

public bool IsEmpty

{

get { return true; }

}

Step 6 – Run the test and see it pass.

1. Press Shift + Alt + X.
2. See it pass.
3. You’ll get 1/1 passed as result

Step 7 – Refactor for clarity and to eliminate duplications

You bag class should look like

public class Bag

{

private bool _isEmpty;

public bool IsEmpty

{

get { return _isEmpty; }

set { _isEmpty = value; }

}

public Bag()

{

this._isEmpty = true;

}

}

Re run your test and see it pass, with the refactored bag class.

Summary

Now you know how to write a simple test on Microsoft Visual Studio Team Edition For Testers, you’ve seen the development lifecycle of a requirement with VS for Testers.

Today I was asked how familiar I was with TDD and what was my opinion about it. Since I never posted about this I will do so! Later I will post about things like Scrum and TDD using Microsoft Visual Studio Team Edition

Test Driven Development

So What is Test Driven Development? To answer this question I would like to quote Kent Beck. In his book TDD : By example (Addison Wesley Professional, 2003)

“Test Driven Development is defined under the following rules:

• Never write a single line of code unless you have a fallen automation test.
• Eliminate duplication”

The first rule is really clear, it’s means that you must have an Automation Test written before writing any code line. That is because TDD maps a requirement as a test. I think this really straight forward, if you don’t have a test (requirement) why bother? there’s no need to implement write any code. This rule empowers developers to be pragmatic and focused on the solution scope.

The second one states that no code should be duplicated, because code duplication leads to bad software design.  This rule is derived from Extreme Programming where it’s called “Once and Only Once”.

I would like to make clear that it is wrong to think that TDD is about unit testing alone. There’s another kind of test called a Customer Test. Some authors call them functional tests or acceptance tests. These kinds of tests are used to understand and establish functional requirements and customer experience. They try to express what the customer needs and wants. This kind of test is usually implemented with what is called navigation story boards.

KIS (Keep It Simple)

TDD suggests writing the minimal amount of code needed to successfully run a test and nothing else. That means you should only satisfy current requirements. Although this may seem obvious to a lot of people, this is usually not so. Most developers often write code to cope with requirements that they think might pop up in the future and by doing so they add code that is not needed at the moment. TDD is strongly against this kind of behavior; remember TDD is to keeping the project on scope.

Many people ask me, how to recognize if the are writing good TDD code? One alternative may be looking at the following checklist:

• Is the code appropriate for the intended audience?
• Is the code passing all the tests.
• Is the code communicating everything it needs to (Remember no more & no less)
• Is the code written in the simplest way (I strongly recommend you to read Steve’s McConnell Code Complete 2^nd Edtion).

Refactoring is the key

I suggest you to follow these steps when writing tests, as guide for good TDD practices:

1. Write the test code
2. Compile the test code (If you are following the list, it  will failed because you haven’t implemented the actual code)
3. Only write just enough code to compile.
4. Run the test and see it fail.
5. Implement just enough to pass the test
6. Re run the tests and see them pass.
7. Refactor for clarity and to eliminate duplication (Remember the 2^nd rule!).
8. Repeat this until your code looks as simple as it can.

When you are finished implementing the code you’ll be able to test future changes on the program. There should be minimal usage of the debugger because the steps are so small that you should know which change was the one that caused the tests to fail.

“Working in small, verifiable steps increase your speed in moving forward because you will be moving with more confidence; the confidence is the result of feedback that running the tests provides your” (Extract from TDD in Microsoft.net, Newkirk & Voronstov, MS Press, 2004).

Summary

TDD is about keeping the code as small as you can (by avoiding the things that you don’t need right now and avoiding duplication with refactoring).