.NET.Refactor()

We all know that the main idea behind TDD is the Red, Green, and Refactor. Well, when we go to make our tests green, how are we going to do that?

 

One of the approaches is to make functional code (which I prefer) and the other is the adversarial approach.

 

Adversarial? What the heck is that?!

 

Well, if you look up the word Adversary the meaning is simple:

 

“a person, group, or force that opposes or attacks”

 

The meaning of Adversarial is:

 

“Relating to or characteristic of an adversary; involving antagonistic elements”

 

How in the world does this relate to code?

 

Okay, so have you heard of ping pong programming? If not, here is a short definition. You have 2 programmers (maybe more, but probably not). One programmer writes the test, the other programmer writes the code to make the test pass. The cool thing is you sit on the same computer and pass the keyboard back and forth.

 

Well, the adversarial part is when you pass the keyboard to the person who is going to implement the code (part of the ping pong process). Not only that but they take the naïve approach and they do the bare minimum and/or the most simplistic approach to making the test pass.

 

Example:

 

        [Test]

        public void TestMe()

        {

            Assert.That(MyNameIs() == “Jason”);

 

        }

 

        private string MyNameIs()

        {

            return “Jason”;

        }

 

What you see here is the bare minimum. You are returning the most minimal answer to satisfy the test.

Okay, so where does adversarial come in?

 

I am going to quote a section from “Adversary System – A Model of Conflict-solving Procedure”

 

Begin Quote:

“Two methods have been used to construct the theoretical model of the adversary process. One method begins from the initial state of conflict between two sides and conceives of the ideal conflict-solving process as a simulation of, and substitute for, the private war between them. This leads to the central image of proceedings as a contest of two sides before the conflict-resolver. The task is then to develop procedural arrangements logically following from this central image. For example, if the adversary judge were permitted to inquire into facts not in dispute between the parties, the proceedings to determine these facts would “logically” cease to be a party contest. Consequently, the adversary model denies to the judge any independent powers to inquire into facts.”

End Quote

Wow, how do we interpret that? If you follow what this is saying, you realize that we code the same way. We write a test and then our adversary writes the stuff to make the test pass. When the person creates a naïve answer that can create for sure a conflict between the developers. When the developer does the bare minimum, it can lead to irresponsible coding.

 

That brings us to my next point.

 

Irresponsible coding. This approach is very irresponsible, in my opinion. If you are going to do the bare minimum, then you are not doing your job. I don’t feel that having a static answer to logic is the way to make your test pass. Doing it like this limits your thinking process and hinders you from looking at what your application should be moving towards.

 

So all in all, I think we should be adversarial, however don’t be naïve and limit your methods to static responses. Be adversarial by challenging each other to create awesome logic to fulfill the test requirements. Challenge each other and become the adversary in programming which can be fun and challenging all at the same time. Just get rid of the naïve thinking.

Oh boy, there have been a ton of discussions and articles about the usage of the var in c# development.

 

My perspective on this is that developers are being too dogmatic in their views when it comes to the usage of the var.

 

Okay, so what do I mean by this? Let’s play devils advocate on both sides. I am only going to give a few examples of the pro’s and con’s of the var usage. There are many articles out there if you would like to see an in depth usage of the pro’s and con’s. The point of this article is to help you be less dogmatic about the usage of var.

 

First, let’s take the “I do not support the var” approach.

 

Point 1: I think it makes the code much more difficult to read.

Point 2: The developer’s intent is not immediately obvious.

Point 3: It can be overused hence causing confusion in code.

 

Okay, now we have seen lots of points in regards to the do not support perspective, let us know look at the “I do support the var” approach.

 

Point 1: Var removes code noise.

Point 2: Var forces initializing to not null values.

Point 3: Var introduces flexibility inside the method scope.

 

 

If you really dig deep in these ideas, from both sides, you realize that both sides can be valid. Well, why don’t we take a less dogmatic approach and come up with the following points.

 

Point 1:

 

Use var when necessary. There are many scenarios where you may want to use var.

            Example:

            Don’t use var like this:

            var amount = engine.GetAmount();

            var amount = 10;

            var name = “Jason”

           

You get the picture. These examples show the un-necessity usage of var. For one, the first example shows that you have to clue what the type is unless you go into the method GetAmount(). The 2^nd two are pointless because you know that name is going to be a string, you might as well just make it a string. The amount = 10, this could be an int, decimal, float or whatever. Hence, you need to have a type that indicates what that number really is.

 

            Example:

            Use var like this:

            var myList = new List<SomeObject>;

            foreach (var foo in barCollection)

           

Here you can see that you are declaring a list object, when you have a bunch of those (I think have had 10 or 12 in a row before) your code then does become unreadable. If you use var, you are giving an explicit definition to your variable, so you don’t care that you are using var. Also, why mess up your foreach with large variable names when you can declare the looping variable with a var making it much easier to read.

 

Some people will argue that putting a var in the looping variable in a foreach is not something you want to do. This is up to your personal discretion. Use it wisely.

 

 

So, back to the original point of this blog about being too dogmatic about the usage of var. We all need to sit back and look at the big picture. We need to use var when it is needed, and not use it when it does not make sense. If you can be less dogmatic about your approach to the usage of var, then you will for one, become a better programmer, for two, you will get to use a powerful feature of c#.

 

 

First and foremost, what is TDD? All TDD really is, is the ability to code your application so that you can test any behavior changes with code changes in the future.

 

!!Screech!!

 

STOP! Did I just say BEHAVIOR changes? I sure did. TDD is not about finding bugs, like most people think about, it is about testing the behavior of your application and making sure that if you make a change to your application the behavior of your application does not break.

 

So does this mean we are really talking about Behavior Driven Development (BDD)? No! This has nothing to do with BDD. That is a whole different topic.

 

What does this mean?

 

Let’s move into an example:

 

Bob the wonder programmer is making a brand spanking new calculator! This calculator is top notch and above the trend with functionality. His calculator will be able to add two numbers together! Isn’t that just amazing?

 

Anyway, Bob goes out and creates a method like this:

 

        public int Add(int x, int y)

        {

            return x + y;

        }

 

This method is super simple if you ask me. Okay, so what is really happening here? You would say something like “Duh, it is adding x and y and returning the result.” Well, you are correct. This is exactly what it is doing. This is the designed behavior of this method. So what happens if we change the method to the following?

 

        public int Add(int x, int y)

        {

            return x + y + x;

        }

 

Is this a bug or a behavior change? It all depends on the person you are asking. If the intent of the change is behavior then it is a behavior change. If the intent was not intended, then it is a bug. However, because the behavior of the method changed, we need to know somehow so our application breaks.

 

Now, all things considers, yes, this is a bug. Don’t get me wrong, a bug is a bug and this problem will be reported as a bug. The point of all of this is to understand that you need to look for behavior changes when you are using TDD.

 

So how are we going to write a test which will allow us to test the behavior of our methods?

 

Using your favorite testing framework (I am using NUnit) you can begin like this:

 

using NUnit.Framework;

namespace Tester

{

    [TestFixture]

    public class TestClass

    {

        [Test]

        public void AddOnePlusOneAndGetTwo()

        {

           

        }

    }

}

 

Looking at this I have the basic shell for my test. What I am going to do next is simple. I am going to write my test for a new method (“Add”) and using Resharper (get it if you don’t have it) I will create my methods and execute my tests.

 

I now have my shell of a test, but my method does not exist yet:

 

  [Test]

        public void AddOnePlusOneAndGetTwo()

        {

            int x = 1;

            int y = 1;

            int z = Add(x, y);

            Assert.That(z == 2);

        }

 

Part of TDD, is to write your test first and then create your methods after the fact. Why do we do this? Because we need to understand what our application is going to do before

 

Okay, using my awesome resharper tool, I created my method (which does reside in the same class as my test, for now – you can move your methods and classes out later, this is part of the refactor process).

 

        private int Add(int x, int y)

        {

            throw new System.NotImplementedException();

        }

 

~ Off Topic ~

 

One of the important factors about Test Driven Development is the following:

 

RED

GREEN

REFACTOR

 

What does this mean actually? Red means you write your test to fail. Fail?? Why in the world would you want your test to fail?

 

You want your test to fail so you know you are testing the right method. What happens if you write a test and you call a method and you are not 100% sure you are calling the right method. This can happen when dealing with overloads.

 

Green means make your test pass. Simple enough.

 

Refactor is just what it means. Refactor your code into a usable design pattern that fits your application. Repeat as necessary. As you refactor your code you may not always get the red again. This is a good thing. If you do get red, something bad happened and you need to fix it.

 

~ Back on Topic ~

 

So, we are going to go ahead and run our test for the first time with our method that we created.

 

We get the wonderful error:

 

System.NotImplementedException: The method or operation is not implemented.

 

This is what we expected. Our test failed. Now, we are going to make our test pass.

 

To do this, we can do one of two things. We can write functional logic or we can write a hard code value as the return type. Granted, a hard coded value will make your test pass and you can refactor that later. However, I personally think it is a waste of precious coding efforts just to make your test pass. Take the time to write your logic to make your test pass. You will feel a bit more warm and fuzzy inside knowing that you are getting closer to the finished product.

 

Our functional method:

 

        private int Add(int x, int y)

        {

            return x + y;

        }

 

Excellent, we have a functional and logical method. Now when we run our test we get the following:

 

Success

 

Okay, as simple as it may sound we are testing the behavior our method. The behavior is the fact we are adding two numbers together.

 

So, what happens if the behavior of our application needs to change? Some vortex of quantum physics comes about and changes the thought processes of all our brains and says that when we add we really need to subtract!

 

Well, that sure would be a behavior change now wouldn’t it? (You can see where this is going can’t you?)

 

So, I go into my method and I change my + to a -:

 

        private int Add(int x, int y)

        {

            return x – y;

        }

 

Now, if I did not have any tests the application would still run. It would still call the method and it will do its calculations and return a number. We would not receive an error. The method may be return the right result (in our strange world) but since the behavior changed, we don’t know about it.

 

We can find out by running our test:

 

NUnit.Framework.AssertionException:   Expected: True
  But was:  False

 

Oops! Our test failed! This could mean one of two things. Our test is no longer valid, or our code is wrong. Since we are changing the behavior in our design, the test is no longer valid. We can both delete the test and write a new one, or we can modify the test to pass. Typically if we are going to change the behavior of our application we are going to modify the test. If the test was really expecting us to add (in the real world), yes we would have a “bug” and we would need to go fix the code.

 

Summary

Test Driven Development is used to determine the behavior of your application is working the way it should be working. TDD is (by concept) used for looking for bugs (which is really just a change in how the behavior works).

 

If you can wrap your head around the fact that you are not testing for bugs you will become an even better programmer when working with any type of application.