.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.