Practical Testing: 19 - Removing the duplicate code

| 5 Comments

The code in the last two articles in the "Practical Testing" series have contained a considerable amount of duplication. This came about for a couple of reasons. Firstly part 17 was a bit rushed and secondly it was useful to compare the CCallbackTimerQueue implementation with the CCallbackTimerQueueEx implementation. I'm also a firm believer that in this kind of situation it's better to get both sets of code working independently and then refactor to remove any duplication rather than attempting to design a duplicate-free solution from the start.

Anyway, this time around we'll remove the duplication by creating a base class that does 99% of the work and then have our two timer queue implementations inherit from it.

It's actually easier to think about the differences between CCallbackTimerQueue and CCallbackTimerQueueEx rather than the duplicate code since they share so much code! The main differences are that CCallbackTimerQueueEx uses GetTickCount64() directly whilst CCallbackTimerQueue fabricates a 64-bit tick count from GetTickCount(). By hoisting most of the code from CCallbackTimerQueueEx into our new base class, CCallbackTimerQueueBase, we can have CCallbackTimerQueueEx provide an implementation of the abstract method, GetTickCount64(), which simply returns the tick count. Then we can remove the shared code from CCallbackTimerQueue and have it use the slightly more complex implementation of GetTickCount64() that it requires.

Finally there's the whole concept of the 'maintenance timer' that CCallbackTimerQueue uses. This can also be hoisted into the base class, made slightly more generic and CCallbackTimerQueue can then set and manipulate its maintenance timer by calling the appropriate methods on its base class.

Once again we can be sure that we haven't broken anything because our tests still run. There's still some duplication in the tests and, perhaps, we'll address this next time...

Code is here and the new rules from last time apply.

5 Comments

Len,

Should not this series of posts on testing be called as "Developer Testing"? The content that you are covering is in developers language and talks about "mostly" code ... Lots of testing happens at GUI level and people scenarios/platform based tests. Calling developer testing as "practical" testing -- in my opinion as "inappropriate" - gives the impression that any testing that does not use the code is "impractical" ....

What do you think? Do you appreciate that part of testing that does not involve working with the code "directly" and do you think that kind of testing is significant enough?

Shrini Kulkarni
shrinik@gmail.com

It states quite clearly in the introduction to the series that we're talking about Test Driven Development and Unit testing. It's "Practical" as in this definition "involving experience or actual use rather than theory" of the word.

I guess the series could be called "Applied Test Driven Development and Unit Testing with C++" but that's a bit long winded...

>> It states quite clearly in the introduction to the series that we're talking about Test Driven Development and Unit testing.

If this were to be a series about TDD and Unit testing --- why use an umbrella term "testing" which is a more like super container in which "unit testing" is an element? What this series would mean to a tester who does testing but not working with code (at least directly)?

Using a generic term "testing" to mean an activity in the universe of testing will surely confuse those who donot test by using code ...

How about titles like

"Practical TDD and Unit Testing"?
"Applied TDD and Unit Testing" ?
"Experiences with TDD and Unit Testing"?
"Getting started with TDD and Unit testing"?

The main confusion is that you choose to omit words "TDD and Unit" out of "Practical TDD and Unit Testing" ...

It is not just about Symantics that I have hung up ... you may be loosing lots of potential readership and google hits as your serise title does not have those magic words "TDD and Unit"

Shrini Kulkarni

Ah well, I suppose you need to be precise to be a good tester ;)

Leave a comment