Lessons learnt…


The past three articles have been quite a learning experience.

I posted the articles on http://angband.oook.cz/rgrd.php for review, and the responses I received were not exactly what I expected (to say the least).

I don’t know what I was hoping for, maybe comments on the structure, thought processes, algorithm, implementation, etc.

Mostly it was a case of people commenting on the quality of the unit tests I was writing in order to test the new functionality. The sad thing is that they were exactly right. Those first tests were total junk, the current ones are maybe only slightly better. And that’s my conundrum, I have no idea how to write better tests. I find it difficult to write a test when I have to write the test before I write the code.

Is this an artifact of TDD that I didn’t anticipate, am I not taking enough time to think about the tests before writing them, or am I just a dumb ass (probably).

Take for example the following test. In this test I’m trying to test the requirement of picking a random cell and flagging it as visited.

        [Test]

        public void TestPickRandomCellAndMarkItVisited()

        {

            Map map = new Map(10, 10);

            map.MarkCellsUnvisited();

 

            int xLocation = Random.Instance.Next(map.Width – 1);

            int yLocation = Random.Instance.Next(map.Height – 1);

 

            map[xLocation, yLocation] = true;

 

            Assert.IsTrue(map[xLocation, yLocation]);

        }

The comments on this test was that I’m just testing the .NET framework’s ability to set a value to “True”. I agree this isn’t really testing functionality of the application. However, when I wrote the test i.e. before any code existed I was trying to write a test (taking into account TDD) that would satisfy the requirement of picking a random cell and flagging it as visited.

In hindsight this test should probably have been written to call a method such as map.PickRandomCellAndFlagItVisited() then the test should have enumerated all the cells in the map to test if one had been flagged as visited.

The next test is even more pointless.

        [Test]

        public void TestGeneratorInstantiation()

        {

            Generator generator = new Generator();

            Map map = generator.Generate();

 

            Assert.IsNotNull(map);

        }

Why did I write it? To force myself to implement a Generator class and to add a Generate method. Am I not getting TDD? One suggestion was to enumerate all the cells in the map and again test if one had been flagged as visited as per the first test. Sounds good, basically I’m testing that the Generate method satisfies the current requirements of the algorithm. This is probably good enough for now and more meaningful than its current state.

I just wonder what happens as I continue to implement the algorithm. The test will fail at some point. Does that invalidate the test or is it just time to refactor it. We can refactor the test to pass in this case, but then that initial test is lost. Maybe that’s OK and exactly in the spirit of TDD.

Time to update the articles.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s