Hey Verg,

Sometimes when TDDing and I run into this type of problem. I stop and remember to ask, what am I doing? What is the intention of the SUT, not what is the implementation. How come you need a class that acts like a facade for your aggregates. Maybe something else is screaming to get out? Did you just say to your self I need to have this class? This is what they say is is BUFD writ small. I'm not saying that your shouldn't do this, but it can trap you into making a least effective design decision. Something the Continuous Integration Crowd talks about, is that you always turn in your code at the end of the day only after your tests pass. If you can't do that. Just delete the code and start over the next day. For me, if it's not the end of the day I will delete the code and go someplace else for a bit. Maybe look to refactor my code base. Spend 15-30 minutes refactoring, then go back to writing the code again.

Hope this helps!

gutzofter@yahoo.com

Quote:Original post by gutzofter
Hey Verg,

Sometimes when TDDing and I run into this type of problem. I stop and remember to ask, what am I doing? What is the intention of the SUT, not what is the implementation. How come you need a class that acts like a facade for your aggregates. Maybe something else is screaming to get out? Did you just say to your self I need to have this class?

Hey thanks for the insight, gutzofter... its quite helpful.

The intention of the "software", in this case, was to take a raw bitmap and convert it into a "useable" bitmap... meaning 1) flip it 2) convert it to the current screen res.

There are several sub-responsibilities... and those mapped to separate classes.

But the "glue" code, in this case, is what delegates these responsibilities... the "BitmapTransform" class, if you will.

Quote:This is what they say is is BUFD writ small. I'm not saying that your shouldn't do this, but it can trap you into making a least effective design decision. Something the Continuous Integration Crowd talks about, is that you always turn in your code at the end of the day only after your tests pass. If you can't do that. Just delete the code and start over the next day.

Wow... guess that works :)

Quote:For me, if it's not the end of the day I will delete the code and go someplace else for a bit. Maybe look to refactor my code base. Spend 15-30 minutes refactoring, then go back to writing the code again.

Hope this helps!

Surely it does.

However, I think my problem can be traced directly back to not using stubs/spies correctly.

Instead of fully controlling the outputs and inputs of the stubs, like I should have, the stubs were subclassed from the real components, (meaning the SUT would call actual components instead of spies through virtual functions) ...making my unit tests more into integration tests... because I had to come up with real data to feed in!

I had to fake some bitmaps at 16-bits, for instance, and then come up with real "result" bitmaps at 32-bit, for instance. THAT's what took so long.

I retraced my steps a bit these last couple days... and created FULL spies that are fully configurable to 1) record all their inputs and, based on the inputs 2) return a value that I've set up for the input. (std::map takes care of the mapping).

This (of course) means I can feed the spies complete nonsense data... (which is much easier)... because all that really matters is what the SUT does with those indirect inputs/outputs.

The work seems to be much easier when it's more configurable like that.

There are still some tricky bits... like how to "sense" through mock APIs... ("memcpy", for instance)... to figure out if the bitmap was actually "flipped"... but I figured out a way to handle that.

...

More in a later entry... and thanks for your input!

Uprate for you.


Chad

It is good that you are working your way through the testing paradigm. Is there some way to get a copy of your source code? I'm interested in testing graphic renderers. I would like to see some code to see if TDDing one makes it easier to unit test the code that utilizes the renderer.

Joe Gutierrez

Quote:Original post by gutzofter
It is good that you are working your way through the testing paradigm. Is there some way to get a copy of your source code? I'm interested in testing graphic renderers. I would like to see some code to see if TDDing one makes it easier to unit test the code that utilizes the renderer.

Hey Joe...

Sorry I didn't get back to you right away (class reunion over the weekend)...

I can't release the code to you (not mine [smile]) but I've been thinking about showing an example (step by step) of what I'm doing, including the building of spies/stubs (which example is sorely lacking on the web or in print, IMO).

I'll have to figure out how to capture a session (VCR?) and then I'll translate that to print and put it here for you.

Thanks again.


Chad