Question: When changing an existing test and causes the codes to not compile

[Chengwei Lin]

Hello everyone,

I'm on page 152 and 153 of the GOOS book, and I have a question.

When trying to display more bidding information, the book starts by modifying one existing acceptance test sniperWinsAnAuctionByBiddingHigher(). It changes application.hasShownSniperIsBidding(),  application.hasShownSniperIsWinning(), and application.showsSniperHasWonAuction() from no parameters to accepting bidding information parameters. Similarly for AuctionSniperDriver.showsSniperStatus(), which was changed from accepting one parameter to four parameters.

My question is, after making these changes, the acceptance test codes do not compile because there is another test that still calls the old versions of the above methods, namely the application.hasShownSniperIsBidding() in sniperMakesAHigherBidButLoses() test. So how should we manage such a scenario in TDD?

If I understand it correctly, TDD encourages us to make small changes to avoid ripping the application apart.

However in this example, it seems either we have to change the other test at the same time, or we have to keep both the old and new versions of the methods to keep the codes compile. To me, this implies that we will either be distracted from changing just one test, or we will have to maintain two versions of the codes at the same time, which is also a distraction, and a maintenance risk to me.

I was wondering if I misunderstand anything or if there is a better way to handle this common situation in TDD?

Thanks,
Chengwei

[Steve Freeman]

Thanks for your question.

Of course the answer is "it depends". Usually these transitions are very short-lived, so it's not so bad to have slightly ugly code or duplication as long as it's not left forever. Brian Marick (I think) once talked about this in terms of tension-and-release: moving through the unbalanced code until one gets to a new stable point.

It's good to have the technique so that one can move in very small steps. Sometimes it really gets you out of a mess, and it's a valuable thinking tool. And sometimes, one just bashes through a change that might be larger than the ideal like to get around some clumsiness in the code.

In this case (and I've forgotten the code), either temporary solution you mention could work. If you have two versions of a method, maybe one can forward to the other with fixed arguments.

I guess the important things are: that changes can be much smaller than most people are used to, and learning to notice when one has "lost control" of the code and it's time to roll back and take another run (another underused technique).

Does that help?

S

[Chengwei Lin]

Hi Steve,

Thanks for your response. Yes, it helps. At least I know that my two temporary solutions are reasonable, and you also give me a concrete suggestion (forwarding the call with fixed arguments).

Maybe I'm just not used to the "tension-and-release" transitions and need more practices. I will certainly do that and see of I have more to share with you.

Thanks a lot,

Chengwei

Steve Freeman 在 2021年12月22日 星期三上午3:03:50 [UTC+8] 的信中寫道：

[Steve Freeman]

Yes. It does take practice to get used to any new technique. It's also a good idea to push things too far in various directions to help understand where the limits are (rather than where one fears they are). This is a nice example of practice https://developerhandbook.stakater.com/content/architecture/object-calisthenics.html

Good luck.
S