One thing that I'll offer (and this may or may not be applicable) is
that I rarely find a need for an "equals" function.  Most of the time,
some members matter more than others and I can solve the problem by
writing a more focused well named function which matches against a
subset of the members of an object.  The exception is when I'm dealing
with a context which already requires an "equals" function.
Otherwise, equality is a slippery notion and it's usually more general
than the immediate need.

Michael Feathers

On Tue, Dec 22, 2009 at 11:53 PM, liam mail <liam.list@...> wrote:
> 2009/12/22 Martin Hauner <hauner@...>
>
>>
>>
>> Hi,
>>
>>
>> On 22.12.09 12:07, liam mail wrote:
>> > I am not sure I understand as C++ has an "isEqual" function already it is
>> > called the equality operator.
>>
>> Yes but with objects containing pointers to other objects the default
>> implementation is usually not what you want.. :)
>>
>> --
>> Martin
>>
>>
> You have read more into my comment than was there. I did not mention the
> default operator only that creating an "isEqual" function is not needed,
> unless there is more information which you have not given, as the operator
> can do the work. It is similar to creating an "init" function to do the work
> of the constructor.
> Liam
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

2009/12/16 showell30 <showell30@...>

>
>
>
> --- In
testdrivendevelopment@yahoogroups.com<testdrivendevelopment%40yahoogroups.com>,
> Olof Bjarnason <olof.bjarnason@...> wrote:
> >
> > Thanks for sharing this!
> >
> > I really like your minimalistic, test-framework-free approach to the
> problem
> > ;)
> >
>
> Thanks!
>
>
> > You might be interested in my youtube-videos featuring how I TDD in
> Python,
> > under Ubuntu:
> >
> >
>
http://www.youtube.com/watch?v=sD6qzJNQEpE&feature=PlayList&p=5F75235C3BCC4172&i\
ndex=0
> >
> > It's a really simple problem (parsing a URL-string) but I think it
> > demonstrates my TDD-approach anyway.
> >
>
> I just watched it! Is part four still on the way? It looked like your tests
> were fairly complete, but you were still struggling a bit to make the
> implementation pretty. It seemed like temporary variables were hard to give
> good names after you did "split," so I was wondering why you did not try
> tuple assignment?
>
>
It is now. And yes, tuple assignment was used to make the code more
readable, plus a local function.

http://www.youtube.com/view_play_list?p=5F75235C3BCC4172


>
>



--
twitter.com/olofb
olofb.wordpress.com


[Non-text portions of this message have been removed]

2009/12/22 Martin Hauner <hauner@...>

>
>
> Hi,
>
>
> On 22.12.09 12:07, liam mail wrote:
> > I am not sure I understand as C++ has an "isEqual" function already it is
> > called the equality operator.
>
> Yes but with objects containing pointers to other objects the default
> implementation is usually not what you want.. :)
>
> --
> Martin
>
>
You have read more into my comment than was there. I did not mention the
default operator only that creating an "isEqual" function is not needed,
unless there is more information which you have not given, as the operator
can do the work. It is similar to creating an "init" function to do the work
of the constructor.
Liam


[Non-text portions of this message have been removed]

Hi Martin,

I will try it like you suggest. Let's see how much code test code will come
> out if it.. :) But it looks like a lot of effort for such a "simple" mehod.
>

LOL Yeah, I might balk, too, in your situation. I've never dealt with
equality method on more than three or four members. That keeps the effort
tolerable.

... which leads me to a few questions: Does your class need 30 members? Must
they all be involved in determining equality? Would it make sense to break
the big class into smaller, more focused ones, which then become members of
the main class? (e.g. one class for repo info, one for conflict info, one
for props info, one for comment info, etc.)

Dale

--
Dale Emery
Consultant to software teams and leaders
Web: http://dhemery.com
Weblog: http://cwd.dhemery.com


[Non-text portions of this message have been removed]

Hi,
Haven't got the chance to check out your example but sounds good. There is a
TDD problems site where you can upload your code.
http://sites.google.com/site/tddproblems/

Cheers

2009/12/16 showell30 <showell30@...>

>
>
> Here is yet another take on the old classic, the Bowling Game:
>
> http://shpaml.webfactional.com/misc/bowling.html
>
> To help capture the evolutionary design of the problem, I kept diffs from
> all 28 green bars leading up to the final^H^H^H^H^H^H current design, and
> then added commentary.
>
>
> http://showellonprogramming.blogspot.com/2009/12/bowling-game-in-python.html
> The sequence was as follows:
>
> PROBLEM STATEMENT
> INFRASTRUCTURE
> PASSING TEST
> FREE PASSING TEST
> REFACTOR TESTS
> PASSING TEST
> REFACTOR CODE
> REFACTOR CODE
> PASSING TEST
> REFACTOR TESTS
> FREE PASSING TEST
> PASSING TEST
> PASSING TEST
> FREE PASSING TEST
> PASSING TEST
> PASSING TEST
> PASSING TEST
> REFACTOR CODE
> REFACTOR TESTS
> REFACTOR CODE
> REFACTOR CODE
> REFACTOR CODE
> PREFACTOR CODE
> FREE PASSING TEST
> REFACTOR CODE
> REFACTOR CODE
> REFACTOR CODE
> REFACTOR CODE
> FREE PASSING TEST
>
> I hope this might be of interest to some folks as a case study/teaching
> aid/etc.!
>
> I also talk a bit about the exercise in my blog entry:
>
>
> http://showellonprogramming.blogspot.com/2009/12/bowling-game-in-python.html
>
> Cheers,
>
> Steve Howell
>
>
>



--
Carlos Ble
www.iExpertos.com
www.carlosble.com


[Non-text portions of this message have been removed]

Hi Dale,

On 22.12.09 12:04, Dale Emery wrote:
>
>
> Hi Martin,
>
> Do you tdd isEqual?
>
> Usually, yeah.

I will try it like you suggest. Let's see how much code test code will come out
if it.. :) But it looks like a lot of effort for such a "simple" mehod.

Thanks.

> Dale

--
Martin

Hi,

On 22.12.09 12:07, liam mail wrote:
> I am not sure I understand as C++ has an "isEqual" function already it is
> called the equality operator.

Yes but with objects containing pointers to other objects the default
implementation is usually not what you want.. :)

--
Martin

2009/12/22 Martin Hauner <hauner@...>

>
>
> Hi,
>
> I have a C++ value object which is fed from a c struct that comes from a
> third
> party library (in my case subversion). The c struct has about 30 members
> and my
> value object copies everything to members variables to get rid of the low
> level
> c stuff.
>
> Now I like to have an isEqual method on this object.
>
> Do you tdd isEqual? If so how?
>
> I have decided to just implement it without test and be bitten by the
> member I
> forgot to compare ;-)
>
> --
> Martin
>
>
I am not sure I understand as C++ has an "isEqual" function already it is
called the equality operator.
Do you tdd isEqual? If so how?
If it is not implemented using a simple POD a == b then yes I would test it,
I assume that the low level C stuff you refer to is C style strings and
pointer management, otherwise it is not clear why you have done as you have,
therefore I would test it. Comparing using an object with know values all
correct. For each member variable that is considered in the equality compare
use a correct and incorrect value.


[Non-text portions of this message have been removed]

Hi Martin,

Do you tdd isEqual?


Usually, yeah.


> If so how?
>

First test:
a = an object of the class you're testing;
assertTrue(a.equals(a));

Next test:
a = an object of that class;
b = a different object for which every member that matters equals the
corresponding member in a.
assertTrue(a.equals(b));

For each member that matters to equality, write a test like this:
a = an object of that class;
b = an object that differs from a only in that one member;
assertFalse(a.equals(b));

If there are members that do not matter to equality, write one or more tests
like this:
a = an object of that class;
b = another object that differs from a only in the values of one or more
don't-care members
assertTrue(a.equals(b));

Dale

--
Dale Emery
Consultant to software teams and leaders
Web: http://dhemery.com
Weblog: http://cwd.dhemery.com


[Non-text portions of this message have been removed]

Hi,

I have a C++ value object which is fed from a c struct that comes from a third
party library (in my case subversion). The c struct has about 30 members and my
value object copies everything to members variables to get rid of the low level
c stuff.

Now I like to have an isEqual method on this object.

Do you tdd isEqual? If so how?


I have decided to just implement it without test and be bitten by the member I
forgot to compare ;-)

--
Martin

Hello everyone,

we are undertaking a study on how developers contribute to both open and
closed source software projects. Please help this research by taking this
short 10 (+3) question survey!

http://osr.cs.fau.de/surveys/index.php?sid=16947&lang=en

We will of course publish the results of this study and if you leave your
email address, you can get the results early.

A bit more information for those interested: We are trying to assess the code
contribution distribution, that is, how much code and how frequently people
check-in. More importantly, what they think how they contribute. The answers
are expected to vary, hence the notion of “distribution”. Better understanding
code contribution behavior will help us build better software development tools.

Thanks a lot!

Dirk Riehle

--
Website: http://dirkriehle.com - Twitter: @dirkriehle
Ph (DE): +49-157-8153-4150 - Ph (US): +1-650-450-8550

2009/12/18 vishal_sodani <vishal_sodani@...>

> Hi Nat,
>
> Could you expand on this a little bit?
>
> "The best solution is to make every developer workstation identical, as far as
the project is concerned, so that all team members can use the same config file
to run the system or tests on their workstation"
> In what ways workstation should be identical? I was thinking of having another
database,"test database", which will be recreated on dev's machine every time
integration tests need to be run.

Yes.  That's what I meant.  If at all possible, I'd develop on the
same OS as the app is deployed to, use the same version of the
database server, with the same schema names, port numbers, TNS names,
etc.

--Nat

--
http://www.natpryce.com

Hi Nat,

Could you expand on this a little bit?
"The best solution is to make every developer workstation identical, as far as
the project is concerned, so that all team members can use the same config file
to run the system or tests on their workstation"
In what ways workstation should be identical? I was thinking of having another
database,"test database", which will be recreated on dev's machine every time
integration tests need to be run.
thanks

--- In testdrivendevelopment@yahoogroups.com, Nat Pryce <nat.pryce@...> wrote:
>
> 2009/12/14 twitter.com/nfma <nuno.filipe.marques@...>
>
> >
> >
> > I've done this using the user.name system property with maven and having a
> > conf file per dev in the proj conf folder.
> >
> > That rapidly gets out of control, because either you check a config file
> for every developer into the source code repository, or every developer
> maintains their own copy outside the repository.  In the former case, you
> end up with loads of unused config files as developers come and go, and the
> config files of different developers drift apart over time for reasons
> nobody understands.  In the latter case, it becomes increasingly difficult
> to add config properties and developers spend lots of time working out why
> the system has stopped working locally.
>
> The best solution is to make every developer workstation identical, as far
> as the project is concerned, so that all team members can use the same
> config file to run the system or tests on their workstation.  And make them
> as similar to the production environment as possible. I much prefer to
> install any infrastructure servers on every workstation (database, message
> broker, etc.). Almost all commercial database systems have a free version
> that can run on Windows or Linux. For example, we use the free Oracle 10 XE
> on the desktop and the expensive Oracle 10g serverside and have not noticed
> any differences that affect our systems.
>
> If you need to use services off the workstation, you can do tricks with the
> local /etc/hosts file (Windows has an equivalent) so that different
> workstations resolve the same service name to different IP addresses.  But
> that can make connection issues difficult to diagnose, so I prefer not to.
>
>  --Nat
>
> > 2009/12/14 vishal_sodani <vishal_sodani@...<vishal_sodani%40yahoo.com>
> > >
> >
> >
> > >
> > >
> > > Hi,
> > > I am part of a project which has legacy code.I have started writing some
> > > unit as well as integration tests, which also required some
> > refactoring.Now,
> > > to run integration tests on a developer machine,the connection string
> > needs
> > > to be changed.Since, each developer will have different connection
> > string.Is
> > > there an alternative to this solution? How can I avoid this manual change
> > on
> > > each developer's machine?
> > >
> > > regards
> > > vishal
> > >
> > >
> > >
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
>
>
>
> --
> http://www.natpryce.com
>
>
> [Non-text portions of this message have been removed]
>

On Thu, Dec 17, 2009 at 10:45 AM, nat_pryce <nat.pryce@...> wrote:

> You could use something like Perceptual Image Diff (
> http://pdiff.sourceforge.net/) to assert that the final renderered image
> is close enough to an expected image that the human eye cannot distinguish
> the two.
>

That's an interesting project. Thx for the link.

--
Chris
http://clabs.org


[Non-text portions of this message have been removed]

--- In testdrivendevelopment@yahoogroups.com, Tron Thomas <tron.thomas@...>
wrote:
>
> I am writing classes which will use for rendering 3 dimensional scenes.
> For example, I want to implement a Light class that can be used to light
> the scene.  I am planning for the Light class to make use of OpenGL to
> provide the needed functionality.
>
> When it comes to writing test for the Light class it is desirable to
> isolate the class.  I wondering if this would require the need to mock
> the OpenGL calls a Light instance might make, or would it be okay use
> the OpenGL API's themselves to verify functionality as it is possible to
> query things like the state of OpenGL lighting.
>
> Another thought is to create an abstract graphics interface that could
> be implemented in terms of OpenGL or some other technology.  It is not
> clear this is really necessary, and could be a  lot of work.
>
> What are people's thoughts on how this tested should be approached?
>

Testing graphics operations is tricky because neither interaction testing (mock
objects) nor state-based testing are a good fit.

If you use mock objects or similar technique to define the expected sequence of
graphics operations it is very easy to overspecify the solution.  Some
operations must occur in a strict order (placing lights before drawing polygons,
for example) while others do not (drawing the individual strips that make up a
3D model).   Many times you don't care how the shape that appears on screen is
made up of primitive drawing operations, just that whatever operations you
invoke leave the pixels set the way you want.

However, most graphics APIs do not precisely specify how graphics operations
effect pixel values, so that implementers have some scope for optimisation. 
That means you can't do state-based testing on final pixel values without some
innacuracy.

You could use something like Perceptual Image Diff
(http://pdiff.sourceforge.net/) to assert that the final renderered image is
close enough to an expected image that the human eye cannot distinguish the two.

Thanks great - I would probably seperate the generation of the test data
from the fixture..
Med Venlig hilsen

Klaus Hebsgaard

Website: http://www.hebsgaard.dk
Blog: http://www.khebbie.dk


On Wed, Dec 16, 2009 at 8:46 PM, Chris Morris <the.chrismo@...> wrote:

>
>
> For repeatability, I try to create tests that can create their own test
> data
> from scratch to depend on. This can be a lot of work and yield some large
> fixture classes. Upsides of this work: you may learn some interesting
> details of the system and the fixture classes themselves could grow up to
> become production classes. Downsides: you'll probably make some
> assumptions/shortcuts in your fixtures that restrict the coverage your
> tests.
>
> To compensate for that last downside, it's good to also have some rigs
> (manually executed perhaps) that can load up lots and lots of real data (or
> copies of real data from production) and run that data through your
> production code to help flush out gaps in coverage in your automated test
> suite.
>
>
> On Tue, Dec 15, 2009 at 2:55 PM, Klaus Hebsgaard
<klaus@...<klaus%40hebsgaard.dk>>
> wrote:
>
> > Well actually I think I am pretty sure I know how I would set up test
> > data for a system I own.
> >
> > But what do you do about setting up test data for at system you don't
> own?
> >
> > Do you just find suitable testdata?
> > Or do you actually create test data, and hence take the time to write
> > to the system (which could be a big task)?
> > If you create test data I assume you do it well, like creating a
> > fluent builder or the likes of it?
> >
> >
> > Best regards
> >
> > Klaus Hebsgaard
> >
> > Website: http://www.hebsgaard.dk
> > Blog: http://www.khebbie.dk
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>
> --
> Chris
> http://clabs.org
>
> [Non-text portions of this message have been removed]
>
>
>


[Non-text portions of this message have been removed]

Hello everyone,

we are undertaking a study on how developers contribute to both open and
closed source software projects. Please help this research by taking this
short 10 (+3) question survey!

http://osr.cs.fau.de/surveys/index.php?sid=16947&lang=en

We will of course publish the results of this study and if you leave your
email address, you can get the results early.

A bit more information for those interested: We are trying to assess the code
contribution distribution, that is, how much code and how frequently people
check-in. More importantly, what they think how they contribute. The answers
are expected to vary, hence the notion of “distribution”. Better understanding
code contribution behavior will help us build better software development tools.

Thanks a lot!

Dirk Riehle

--
Website: http://dirkriehle.com - Twitter: @dirkriehle
Ph (DE): +49-157-8153-4150 - Ph (US): +1-650-450-8550

For repeatability, I try to create tests that can create their own test data
from scratch to depend on. This can be a lot of work and yield some large
fixture classes. Upsides of this work: you may learn some interesting
details of the system and the fixture classes themselves could grow up to
become production classes. Downsides: you'll probably make some
assumptions/shortcuts in your fixtures that restrict the coverage your
tests.

To compensate for that last downside, it's good to also have some rigs
(manually executed perhaps) that can load up lots and lots of real data (or
copies of real data from production) and run that data through your
production code to help flush out gaps in coverage in your automated test
suite.


On Tue, Dec 15, 2009 at 2:55 PM, Klaus Hebsgaard <klaus@...> wrote:

> Well actually I think I am pretty sure I know how I would set up test
> data for a system I own.
>
> But what do you do about setting up test data for at system you don't own?
>
> Do you just find suitable testdata?
> Or do you actually create test data, and hence take the time to write
> to the system (which could be a big task)?
> If you create test data I assume you do it well, like creating a
> fluent builder or the likes of it?
>
>
> Best regards
>
> Klaus Hebsgaard
>
> Website: http://www.hebsgaard.dk
> Blog: http://www.khebbie.dk
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>


--
Chris
http://clabs.org


[Non-text portions of this message have been removed]

In my simple particle system, I have an SwtDisplay class with a paint method
(see below). It receives an array of particle objects from the particle
system and renders them. The particle system is completely independent of
rendering - it handles all of the math (and in this case coloring, which you
could argue is an improper coupling), the rendering class handles the
actually drawing and calls to whatever API you have. I could create a
separate OpenGLDisplay class to have it rendered there.

It's been mentioned earlier in this thread that this sort of separation can
have performance concerns in this specific context of game design ... so
keep in mind my example here is for a very (_very_) simple bit of toy code.

If you want to see the whole thing in context, grab a .zip here:
http://clabs.org/dl/partikil, the clparticle.jar has sources (including
tests) inside. Since there's no knowledge of rendering in the particle
system classes, it's easy to test the core classes because there's nothing
to even mock out.

private void paint() {
IParticle[] array = cachedParticleArray;
// at startup, system may ask us to render before we've initialized
if ((canvas != null) && (image != null)) {
bGC.setBackground(canvas.getBackground());
bGC.fillRectangle(display.getBounds());
  if (paintListener != null) paintListener.onBeforePaint(bGC);
  for (int i = 0; i < array.length; i++) {
IParticle particle = array[i];
org.clabs.particle.Color color = particle.getColor();
Color swtColor = new Color(display, color.getRed(), color.getGreen(),
color.getBlue());
try {
int size = particle.getSize();
if (size == 1) {
bGC.setForeground(swtColor);
bGC.drawPoint((int)particle.getLeft(), (int)particle.getTop());
}
else {
bGC.setBackground(swtColor);
bGC.fillOval((int)particle.getLeft(), (int)particle.getTop(), size, size);
}
}
finally {
swtColor.dispose();
}
  }
  bGC.setBackground(canvas.getBackground());
  if (paintListener != null) paintListener.onAfterPaint(bGC);
canvas.drawImage(image, 0, 0);
}
}

On Tue, Dec 15, 2009 at 11:42 PM, Tron Thomas <tron.thomas@...>wrote:

> I'm not sure I follow what you are saying Chris.  If a light is meant to
> implement lighting affects in a scene rendered by OpenGL how can it not
> make calls to OpenGL lighting functions, unless you are advocating for
> create the graphics interface.
>
>
--
Chris
http://clabs.org


[Non-text portions of this message have been removed]

Could be I've missed the point of the question, though. From re-reading your
email, you may already have scene objects and are looking to TDD the
rendering class itself.

On Tue, Dec 15, 2009 at 11:42 PM, Tron Thomas <tron.thomas@...>wrote:

> I'm not sure I follow what you are saying Chris.  If a light is meant to
> implement lighting affects in a scene rendered by OpenGL how can it not
> make calls to OpenGL lighting functions, unless you are advocating for
> create the graphics interface.
>
> --
Chris
http://clabs.org


[Non-text portions of this message have been removed]

--- In testdrivendevelopment@yahoogroups.com, Olof Bjarnason
<olof.bjarnason@...> wrote:
>
> Thanks for sharing this!
>
> I really like your minimalistic, test-framework-free approach to the problem
> ;)
>

Thanks!

> You might be interested in my youtube-videos featuring how I TDD in Python,
> under Ubuntu:
>
>
http://www.youtube.com/watch?v=sD6qzJNQEpE&feature=PlayList&p=5F75235C3BCC4172&i\
ndex=0
>
> It's a really simple problem (parsing a URL-string) but I think it
> demonstrates my TDD-approach anyway.
>

I just watched it!  Is part four still on the way?  It looked like your tests
were fairly complete, but you were still struggling a bit to make the
implementation pretty.  It seemed like temporary variables were hard to give
good names after you did "split," so I was wondering why you did not try tuple
assignment?

Hi Tron,

When it comes to writing test for the Light class it is desirable to isolate
> the class.  I wondering if this would require the need to mock the OpenGL
> calls a Light instance might make


It's not required, of course, but that's the way I'd go. I like to provide a
layer of insulation -- an adapter class between code I write and third party
code. This takes more work up front, but it can simplify the job of
upgrading the third party library to new versions. When the library changes,
I don't have to search through all of my code to find the calls; I have only
to review the adapter. In this way, the adapter reduces your exposure to
quirks and changes in the third party code.

or would it be okay use the OpenGL API's themselves to verify functionality
> as it is possible to query things like the state of OpenGL lighting.
>

Yes, that's always a possibility. The drawback is: When there's a defect
that involves Light, where is the fault? Is it in Light? In OpenGL? In the
way Light uses OpenGL? Separating Light from OpenGL gives you an opportunity
to specify the important behavior of each, in a way that allows you to more
quickly trace a defect to the broken code.


> Another thought is to create an abstract graphics interface that could be
> implemented in terms of OpenGL or some other technology.  It is not clear
> this is really necessary, and could be a  lot of work.
>

Here's a way to make it less work: Don't create a whole big abstract
graphics interface. Create a small interface that uses only the features
that Light uses. Add to the interface only when Light (or some other client)
needs an additional feature from the rendering library.

Also, define the interface in terms of Light's needs, which may differ from
the API that OpenGL exposes.

Michael Feathers describes a step-by-step approach to this in his terrific
book Working Effectively With Legacy Code. Bret Schuchert has translated the
approach into a nice series of diagrams:
http://blog.objectmentor.com/articles/2009/12/16/name-that-refactoring-2-version\
-2.

Part of the extra work you mentioned is to set up the mocks, and part of
that is to understand the OpenGL behavior well enough to mock it reliably.
One way to do that is to write "characterization tests" -- that is, tests
that characterize important aspects (more below) of OpenGL's current
behavior.

In addition to helping you understand OpenGL's behavior, characterization
tests also help you to detect behavior changes when up upgrade OpenGL, or
when the test machine or a user's machine has a slightly different version
or configuration. Your characterization tests say "here's the behavior I
depend on," and one fails, you know something changed in the library.

You don't need characterization tests for all of OpenGL -- just the bits
that your classes call. Less than that, even: I tend to write
characterization tests only when I'm puzzled about some quirk of the
library's behavior, when I learn something that surprises me, or when I
discover that my test doubles aren't mimicking the library's behavior well
enough. I write the characterization tests to explore the library's behavior
and quirks; I keep them so that I don't forget what I learned.

So the key elements for me are:
1. An interface (or two or three) defined by Light's needs.
2. An adapter (or two or three) that implements the interface, translates
Light's needs into OpenGL calls, and does nothing else.
3. Test doubles as needed.
4. Characterization tests to capture quirks and to detect changes.

Dale

--
Dale Emery
Consultant to software teams and leaders
Web: http://dhemery.com
Weblog: http://cwd.dhemery.com


[Non-text portions of this message have been removed]

Thanks for sharing this!

I really like your minimalistic, test-framework-free approach to the problem
;)

You might be interested in my youtube-videos featuring how I TDD in Python,
under Ubuntu:

http://www.youtube.com/watch?v=sD6qzJNQEpE&feature=PlayList&p=5F75235C3BCC4172&i\
ndex=0

It's a really simple problem (parsing a URL-string) but I think it
demonstrates my TDD-approach anyway.


2009/12/16 showell30 <showell30@...>

>
>
> Here is yet another take on the old classic, the Bowling Game:
>
> http://shpaml.webfactional.com/misc/bowling.html
>
> To help capture the evolutionary design of the problem, I kept diffs from
> all 28 green bars leading up to the final^H^H^H^H^H^H current design, and
> then added commentary.
>
>
> http://showellonprogramming.blogspot.com/2009/12/bowling-game-in-python.html
> The sequence was as follows:
>
> PROBLEM STATEMENT
> INFRASTRUCTURE
> PASSING TEST
> FREE PASSING TEST
> REFACTOR TESTS
> PASSING TEST
> REFACTOR CODE
> REFACTOR CODE
> PASSING TEST
> REFACTOR TESTS
> FREE PASSING TEST
> PASSING TEST
> PASSING TEST
> FREE PASSING TEST
> PASSING TEST
> PASSING TEST
> PASSING TEST
> REFACTOR CODE
> REFACTOR TESTS
> REFACTOR CODE
> REFACTOR CODE
> REFACTOR CODE
> PREFACTOR CODE
> FREE PASSING TEST
> REFACTOR CODE
> REFACTOR CODE
> REFACTOR CODE
> REFACTOR CODE
> FREE PASSING TEST
>
> I hope this might be of interest to some folks as a case study/teaching
> aid/etc.!
>
> I also talk a bit about the exercise in my blog entry:
>
>
> http://showellonprogramming.blogspot.com/2009/12/bowling-game-in-python.html
>
> Cheers,
>
> Steve Howell
>
>
>



--
twitter.com/olofb
olofb.wordpress.com


[Non-text portions of this message have been removed]

I'm not sure I follow what you are saying Chris.  If a light is meant to
implement lighting affects in a scene rendered by OpenGL how can it not
make calls to OpenGL lighting functions, unless you are advocating for
create the graphics interface.

Chris Morris wrote:
>
>
> Off the cuff I'd say light shouldn't make the OpenGL calls. I wrote a
> simple
> particle system that is separate from the specific rendering - so I
> was able
> to write a renderer in SWT and then again in .NET/WinForms (after
> cross-compiling the .jars with IKVM.NET). Not hard to do - it may seem
> like
> over-design, but I don't think it is and the testability alone will be
> worth
> it.
>

Sounds like you are advocating mocking the OpenGL calls.  I did not
mention in my original post; I am writing in C++ and using cxxtest as
the test harness.  I've never used any of its mock capabilities.  From
what I've read it does have the ability to override global functions
like those I was planning to call from OpenGL, so that approach should work.

Roy Osherove wrote:
>
>
> There's a lot to be said for abstracting away awkward or unusable
> interfaces
> away from the core system.
> that said, sometimes it's too much work and faking that behavior can be a
> time saver as well as more pragmatic.
> if these are interfaces or non sealed classes with virtual methods,
> then any
> of today's isolation frameworks will do (rhino mocks, moq, nmock and
> typemock)
> otherwise typemock would be the only choice besides abstraction.
>

Here is yet another take on the old classic, the Bowling Game:

http://shpaml.webfactional.com/misc/bowling.html

To help capture the evolutionary design of the problem, I kept diffs from all 28
green bars leading up to the final^H^H^H^H^H^H current design, and then added
commentary.

http://showellonprogramming.blogspot.com/2009/12/bowling-game-in-python.html
The sequence was as follows:

  PROBLEM STATEMENT
  INFRASTRUCTURE
  PASSING TEST
  FREE PASSING TEST
  REFACTOR TESTS
  PASSING TEST
  REFACTOR CODE
  REFACTOR CODE
  PASSING TEST
  REFACTOR TESTS
  FREE PASSING TEST
  PASSING TEST
  PASSING TEST
  FREE PASSING TEST
  PASSING TEST
  PASSING TEST
  PASSING TEST
  REFACTOR CODE
  REFACTOR TESTS
  REFACTOR CODE
  REFACTOR CODE
  REFACTOR CODE
  PREFACTOR CODE
  FREE PASSING TEST
  REFACTOR CODE
  REFACTOR CODE
  REFACTOR CODE
  REFACTOR CODE
  FREE PASSING TEST

I hope this might be of interest to some folks as a case study/teaching
aid/etc.!

I also talk a bit about the exercise in my blog entry:

http://showellonprogramming.blogspot.com/2009/12/bowling-game-in-python.html

Cheers,

Steve Howell

Well actually I think I am pretty sure I know how I would set up test
data for a system I own.

But what do you do about setting up test data for at system you don't own?

Do you just find suitable testdata?
Or do you actually create test data, and hence take the time to write
to the system (which could be a big task)?
If you create test data I assume you do it well, like creating a
fluent builder or the likes of it?


Best regards

Klaus Hebsgaard

Website: http://www.hebsgaard.dk
Blog: http://www.khebbie.dk

There's a lot to be said for abstracting away awkward or unusable interfaces
away from the core system.
that said, sometimes it's too much work and faking that behavior can be a
time saver as well as more pragmatic.
if these are interfaces or non sealed classes with virtual methods, then any
of today's isolation frameworks will do (rhino mocks, moq, nmock and
typemock)
otherwise typemock would be the only choice besides abstraction.

On Tue, Dec 15, 2009 at 5:02 AM, Tron Thomas <tron.thomas@...>wrote:

>
>
> I am writing classes which will use for rendering 3 dimensional scenes.
> For example, I want to implement a Light class that can be used to light
> the scene. I am planning for the Light class to make use of OpenGL to
> provide the needed functionality.
>
> When it comes to writing test for the Light class it is desirable to
> isolate the class. I wondering if this would require the need to mock
> the OpenGL calls a Light instance might make, or would it be okay use
> the OpenGL API's themselves to verify functionality as it is possible to
> query things like the state of OpenGL lighting.
>
> Another thought is to create an abstract graphics interface that could
> be implemented in terms of OpenGL or some other technology. It is not
> clear this is really necessary, and could be a lot of work.
>
> What are people's thoughts on how this tested should be approached?
>
>
>



--
Thanks,

Roy Osherove
www.TypeMock.com - Unit Testing, Plain Smart

Author of "The Art Of Unit Testing" (http://ArtOfUnitTesting.com )
A blog for team leaders: http://5Whys.com
my .NET blog: http://www.ISerializable.com
Twitter: http://twitter.com/RoyOsherove
+972-524-655388 (GMT+2)


[Non-text portions of this message have been removed]

2009/12/15 Chris Morris <the.chrismo@...>

>
>
> Off the cuff I'd say light shouldn't make the OpenGL calls. I wrote a
> simple
> particle system that is separate from the specific rendering - so I was
> able
> to write a renderer in SWT and then again in .NET/WinForms (after
> cross-compiling the .jars with IKVM.NET). Not hard to do - it may seem
> like
> over-design, but I don't think it is and the testability alone will be
> worth
> it.
>
> On Mon, Dec 14, 2009 at 9:02 PM, Tron Thomas
<tron.thomas@...<tron.thomas%40verizon.net>
> >wrote:
>
>
> > I am writing classes which will use for rendering 3 dimensional scenes.
> > For example, I want to implement a Light class that can be used to light
> > the scene. I am planning for the Light class to make use of OpenGL to
> > provide the needed functionality.
> >
> > When it comes to writing test for the Light class it is desirable to
> > isolate the class. I wondering if this would require the need to mock
> > the OpenGL calls a Light instance might make, or would it be okay use
> > the OpenGL API's themselves to verify functionality as it is possible to
> > query things like the state of OpenGL lighting.
> >
> > Another thought is to create an abstract graphics interface that could
> > be implemented in terms of OpenGL or some other technology. It is not
> > clear this is really necessary, and could be a lot of work.
> >
> > What are people's thoughts on how this tested should be approached?
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>
> --
> Chris
> http://clabs.org
>
> [Non-text portions of this message have been removed]
>
>
>
Yes if you are going to abstract the API in use so that DirectX could for
example be used then also the Light would also need to be abstracted. You
are correct that creating an abstract Renderer involves more work and is
actually generally frowned upon in games programming, as you have to reduce
the interface to the lowest common denominator which may all include using
void pointers et al.There are times in games programming where is clashes
with good practice and unit testing.

I assume you are rendering the light on the CPU rather than the GPU, as on
the GPU you are out of look in regards to unit testing, also note that the
features you propose to use are depreciated by the API.


[Non-text portions of this message have been removed]

Off the cuff I'd say light shouldn't make the OpenGL calls. I wrote a simple
particle system that is separate from the specific rendering - so I was able
to write a renderer in SWT and then again in .NET/WinForms (after
cross-compiling the .jars with IKVM.NET). Not hard to do - it may seem like
over-design, but I don't think it is and the testability alone will be worth
it.

On Mon, Dec 14, 2009 at 9:02 PM, Tron Thomas <tron.thomas@...>wrote:

> I am writing classes which will use for rendering 3 dimensional scenes.
> For example, I want to implement a Light class that can be used to light
> the scene.  I am planning for the Light class to make use of OpenGL to
> provide the needed functionality.
>
> When it comes to writing test for the Light class it is desirable to
> isolate the class.  I wondering if this would require the need to mock
> the OpenGL calls a Light instance might make, or would it be okay use
> the OpenGL API's themselves to verify functionality as it is possible to
> query things like the state of OpenGL lighting.
>
> Another thought is to create an abstract graphics interface that could
> be implemented in terms of OpenGL or some other technology.  It is not
> clear this is really necessary, and could be a  lot of work.
>
> What are people's thoughts on how this tested should be approached?
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>


--
Chris
http://clabs.org


[Non-text portions of this message have been removed]