Again, I think you’re misunderstanding what refactoring means. In the case of the first example, the functional requirements were for the game to put the player’s choice in the selected position when they go first. I chose to verify this by checking that the selected position had an ‘X’ in it, made the test pass by hard-coding the GetPosition() method to always return ‘X’, and then refactored to eliminate the duplication between the value returned by the GetPosition() and the value being verified within the test. Here is the important part: In the end, the behavior being verified by the specification did not change. I think this is the key component you’re missing. Refactoring isn’t the process of changing code without introducing new capabilities, it’s the process of changing code without changing the functional requirements.

The process of writing another failing test before introducing generalization, which you’re advocating, is referred to within Test-Driven Development as Triangulation. While this is a legitimate technique, it isn’t set forth as a primary strategy for most cases.

I appreciate that you’re trying to understand the rules and follow them to the letter, as this is often a necessary stage in skill acquisition. I’m not that familiar with Roy’s approach to testing, but I would highly recommend you read the book: Test-Driven Development By Example. The author, Kent Beck, created the Test Driven Development methodology. After consulting his work, I believe you’ll find my example to be a faithful representation of his approach.

Moving beyond an appeal to authority however, what’s more valuable is to understand the reason and value in these techniques. What value are we gaining from writing tests first? What’s the value in Red/Green/Refactor? What are the motivations behind using the strategies of Obvious Implementation, Fake It, and Triangulation? What are the shortcomings? When should you shift into “second gear”? When should you downshift back to taking teeny-tiny steps? Once you can answer these questions, you’ll be on the road to mastering TDD.

Moreover, take from Kent Beck’s TDD methodology, Dan North’s BDD methodology, Steve Freeman and Nat Pryce’s A-TDD methodology, Roy Osherove’s methodology and all the styles, approaches, and theories in between and find a synthesis that helps you be an effective software engineer.

Cheers.

thank you for your answer, I really appreciate the possibility to discuss TDD here on LosTechies.

I begin by quoting you: “What this guidance actually means is that we shouldn’t begin implementing new requirements until a specification is written first” – but isn’t that exactly what you did? In the very first test of Part I, you got the test green by making GetPosition() return ‘X’. Then, in the refactoring phase, you implemented the requirement by adding _layout – without failing test.

What I believe you should have done was to write another test that would fail on that naïve GetPosition() implementation, thus forcing you to fix it – e.g. by adding the _layout member variable. Without the next text, your first test’s requirement was fully implemented – so why bother with _layout?

Replacing the “fake it” solution with some “real” implementation isn’t refactoring, because – well, it changes the business logic. Before the change, your GetPosition() always returned ‘X’, no matter what. Afterwards, it returned the value of _layout. I believe refactoring should not change return values of methods like this. If I’m wrong, then I must say I fail to tell the difference between refactoring and implementation.

I’ve been doing TDD for only a year now, so of course I may be wrong; but from what I know, the “right” way of doing it is to really implement only the requirements that are contained in the tests. This is what I learned from e.g. Roy Osherove’s videos (then again, of course maybe I got it all wrong).

First, let me commend you on having a keen sense of perception. What you’ve discovered is that in Test-Driven Development, much of the implementation of our solutions actually occurs during the refactoring phase. To review, the steps of TDD are as follows:

1. Write a test.

2. Make it compile.

3. Run it to see that it fails.

4. Make it run.

5. Remove duplication.

This process is commonly shortened to Red/Green/Refactor.

Where I believe you’ve misunderstood the Test-Driven Development process is in the Refactor step. In general, refactoring is the process of making changes to an application’s source code without modifying its functional requirements. Refactoring can entail a number of changes, but the TDD process sets forth the elimination of duplication as the primary heuristic for guiding (and restricting) our modifications. There have been a couple of cases where, during the refactoring phase, I’ve extracted a method to help clarify the intent of the code emerging from my example, but for the most part changes have occurred solely to eliminate duplication.

Without a full grasp of the TDD process, The concept of not changing code without a failing test can actually be a little misleading. In fact, it would be impossible to follow the TDD steps without doing this, as refactoring by definition is changing code and refactoring comes after the tests are passing. What this guidance actually means is that we shouldn’t begin implementing new requirements until a specification is written first. If you review the steps you’ve set forth in your comments, I think you’ll discover that you are violating your own rule in that you recommend shaping up the code (unsure what this means exactly) after you’ve made a test green, but before you’ve written another test.

I hope this explanation helps.

I have no problem with “faking it”, but I don’t understand why you actually do the implementation stuff in the refactoring phase. I know you call it eliminating duplicities, but to me it seems like you break one of the rules of TDD: you change production code without a failing test.

I believe the correct steps should be:
1) write failing test
2) make it green
3) refactor – where “refactor” really means to refactor the code: to shape it up without changing the business logic.

What you seem to be doing is:
1) write failing test
2) make it green
3) change the business logic to suit your purpose (without writing any more tests)
4) refactor

I believe there should be at least another failing test between 2) and 3).