using TDD in GUI - land

[Sam Jost]

Hi y'all!

Lately I read a lot about unit tests and test driven development, and
when I luckily received a request for a sufficiently small program I
thought 'hey, lets give it a try'.

So I started a TDD project in c#, with nunit.
Well, at least I tried to start it, I found it very challenging to
think of any tests in the case of a GUI program.
I read 'the humble dialog class' and used the guidelines inside, but
still I stumbled upon problem after problem where reading 'TDD by
example' had not really prepared me for.

Does anyone round here does daily development of GUI programs with
TDD? Someone got a few hints and pointers for a newb?


Sam

[Phlip]

Sam Jost wrote:
So I started a TDD project in c#, with nunit. Well, at least I tried to start it, I found it very challenging to think of any tests in the case of a GUI program. I read 'the humble dialog class' and used the guidelines inside, but still I stumbled upon problem after problem where reading 'TDD by example' had not really prepared me for. Does anyone round here does daily development of GUI programs with TDD? Someone got a few hints and pointers for a newb?

Yes, but not for NUnit or C#.

Does the following VB help?

Load frmMyForm
frmMyForm.Initialize "my data" ' <-- public method

myDataBase.setSomeField("")

frmMyForm.Submit_Click ' <-- pretend to click on a button

Debug.Assert myDataBase.someField() = "my data"

' frmMyForm.Show 1
Unload frmMyForm

We don't need to test that the Submit button itself is clickable.
Refactoring won't easily change that. That logic is in the "GUI Toolkit" -
we want to test only our own "GUI Layer".

We assert that the effect of our click went into the database. Our data
appeared in some field. This would tend to indicate that Submit_Click is the
one that pushed the data into the database.

Next, while programming a GUI we often want to look at its intermediate
state. So I have a commented-out line that would have called 'Show' in Modal
mode. It's Modal so we block all the other tests until we are finished
looking at the window.

If we see anything wrong we must decide to write a test, or to just fix it.
If it's simple, such as two fields overlapping, just go to Design Mode and
drag the fields apart. But if you don't know >why< the fields are
overlapping, a test will help investigate.

What would that look like in C#?

Please report exactly where you get stuck. Remember you must program so that
all tests run without popping up a window. Visual Basic actually becomes
refactorable when you can run a bunch of tests, over and over, without ever
seeing a window!

--
Phlip
http://www.c2.com/cgi/wiki?TestFirstUserInterfaces

[Sam Jost]

"Phlip" <phlip_cpp@yahoo.com> wrote:
Sam Jost wrote: Does anyone round here does daily development of GUI programs with TDD? Someone got a few hints and pointers for a newb?Yes, but not for NUnit or C#.Does the following VB help? Load frmMyForm frmMyForm.Initialize "my data" ' <-- public method myDataBase.setSomeField("") frmMyForm.Submit_Click ' <-- pretend to click on a button Debug.Assert myDataBase.someField() = "my data" ' frmMyForm.Show 1 Unload frmMyFormWe don't need to test that the Submit button itself is clickable.Refactoring won't easily change that. That logic is in the "GUI Toolkit" -we want to test only our own "GUI Layer".We assert that the effect of our click went into the database. Our dataappeared in some field. This would tend to indicate that Submit_Click is theone that pushed the data into the database.

*looks astonished*
You just instantiate the form and manipulate the controls - and I was
making four classes to achieve this with a complicated
master/view-structure: a master class doing the actual work, a view
interface so the master can control the form (that derived from the
view interface) and a class to test the master that used a mock class
of the form with help of the interface - but everything is *very*
indirect with a structure this complicated, and made thinking up tests
hard.


To make your tests work you will have to make most of the controls and
stuff in your form public instead of the normal private, or is there a
way around this?
Next, while programming a GUI we often want to look at its intermediatestate. So I have a commented-out line that would have called 'Show' in Modalmode. It's Modal so we block all the other tests until we are finishedlooking at the window.

Another idea would be to put the location out of sight, to a testing
location where it does pop up but never be seen (like -10000/-10000).
That case should be even more realistic for tests, or not?
If we see anything wrong we must decide to write a test, or to just fix it.If it's simple, such as two fields overlapping, just go to Design Mode anddrag the fields apart. But if you don't know >why< the fields areoverlapping, a test will help investigate.What would that look like in C#?Please report exactly where you get stuck. Remember you must program so thatall tests run without popping up a window. Visual Basic actually becomesrefactorable when you can run a bunch of tests, over and over, without everseeing a window!

You already gave me some stuff to think and try about - I will try to
use your approach for testing and see what it will do to my project to
be. I will write again with my results.

Thanks a lot,
Sam

[Phlip]

> *looks astonished* You just instantiate the form and manipulate the controls - and I was making four classes to achieve this with a complicated master/view-structure: a master class doing the actual work, a view interface so the master can control the form (that derived from the view interface) and a class to test the master that used a mock class of the form with help of the interface - but everything is *very* indirect with a structure this complicated, and made thinking up tests hard.

I'm wondering if those classes gave you any benefit that I missed.

I'm also wondering if C# (and the Java before it) are so wonderful
they force all those extras just to test.

Some toolkits make this stuff easy. For some reason, TCL/Tk is
absurdly easy to "fall into" the right pattern. That was invented
before graphic cards were fast, but after systems like XWindows
provided pernicious abstractions, so Tk had to buffer all activity
into their own object model. >That's< what we're testing.
To make your tests work you will have to make most of the controls and stuff in your form public instead of the normal private, or is there a way around this?

Why?

In the olden days, "Private" was for indirect robustness checks - like
static typing. Tests give direct robustness checks.
Next, while programming a GUI we often want to look at its intermediatestate. So I have a commented-out line that would have called 'Show' in Modalmode. It's Modal so we block all the other tests until we are finishedlooking at the window. Another idea would be to put the location out of sight, to a testing location where it does pop up but never be seen (like -10000/-10000).

On AmigaOS, calling CreateWindow creates a window. It's there before
the function returns. In this case, I will investigate pushing that
window to a screen in the background.

Keeping your fingers on the keyboard, and the editor up with the
keyboard focus, even while GUI tests run, is the ultimate goal!
That case should be even more realistic for tests, or not?

Unfortunately yes.

In theory, testing the raw pixels in the output window's raster is too
far from the source code we are changing.

In practice, that theory depends on an absolutely perfect bug-free
toolkit. Fat chance.

A policy of frequently (but not always) popping that window up, while
developing its features, will provide coverage.

--
Phlip
http://clublet.com/c/c/why?ZenoBuddhism
-- Have a :-) day --

[Andrew Wall]

"Phlip" <phlip_cpp@yahoo.com> wrote in message
news:e6AOa.435$6n7.257@newssvr33.news.prodigy.com... Sam Jost wrote: Does anyone round here does daily development of GUI programs with TDD? Someone got a few hints and pointers for a newb? Does the following VB help? Load frmMyForm frmMyForm.Initialize "my data" ' <-- public method myDataBase.setSomeField("") frmMyForm.Submit_Click ' <-- pretend to click on a button
I have trouble with doing this on at least two counts:
1) Submit_click() is private to the form, unless you go round and change
these events to public
2) The whole of a form is private to a dll. (I use the 'Test Project
references ActiveX DLL' idiom to seperate the tests from the code being
tested.)
We assert that the effect of our click went into the database. Our data appeared in some field. This would tend to indicate that Submit_Click is
the one that pushed the data into the database.
I have tended to wrap the form in a public class. The class methods are
then public or private as required. And classes can be made Public
Multi-Use in dlls
Please report exactly where you get stuck. Remember you must program so
that all tests run without popping up a window. Visual Basic actually becomes refactorable when you can run a bunch of tests, over and over, without
ever seeing a window!
I've been able to TDD some VB6 programs where the test run means many
windows popping up then disappear in a flash. It doesn't seem to extend the
test run by much.


--
Andrew

[Remi Samosiuk]

"Sam Jost" <sam.jost@b-soft.de> wrote in message
news:o1glgvohok6ii0ah8fbf1tjdstomdpsu7e@4ax.com... Hi y'all! Lately I read a lot about unit tests and test driven development, and when I luckily received a request for a sufficiently small program I thought 'hey, lets give it a try'. So I started a TDD project in c#, with nunit. Well, at least I tried to start it, I found it very challenging to think of any tests in the case of a GUI program. I read 'the humble dialog class' and used the guidelines inside, but still I stumbled upon problem after problem where reading 'TDD by example' had not really prepared me for. Does anyone round here does daily development of GUI programs with TDD? Someone got a few hints and pointers for a newb? Sam

Hi !

Unfortunately I have some bad news for you :-(

I tried to programming with TDD in C#, but have problems with GUI and
database testing.
First (like you) i tried to use MVC approach, but have more problems with
that then solutions.
Next I use simple trick (but it takes me month to discover it - heh)

public class MyForm
{
....
protected void button_Click(object sender, EventArgs e)
{
....
}
....
}

public class MockForm : MyForm
{
public void InvokeButtonClick()
{
button_Click(this, EventArgs.Empty);
}
}

And later in test you can just call InvokeButtonClick().

Simple, isn't it :-)

But there are some places that I give up. For example if I want to test that
OpenFileDialog was showed the only solution is to make a separate method for
just show it.

protected virtual DialogResult ShowOpenFileDialog(OpenFileDilaog dialog)
{
return dialog.ShowDialog();
}

In this method I can test later (because it's virtual) how it was
initilized. This is strange for me, to make one method just for show window.

This example is not so awful, worse situation is if you want to simulate
user actions like click. It's simple only with Button class and I dont know
how to do it with DataGrid.

Generally I test only when I can, and have one big problem.
Everywhere where I read about TDD, autor write example with something like
10.30: Start to write test for something
10.33: It failed
10.35: Done, I have green light.
And when I read It, I think that I'm stupid or something, because it takes
me usually 15 or 30 minutes to write a test(because I must write mock class
or mock method, or usually I just don't know how to test something)

Regards
Remi Samosiuk

Java & C# (MCP) developer
-------------------------------------------------
XLogics Polska
email: r.samosiuk@xlogics.pl
email: seer@proton.if.uz.zgora.pl (private)
URL: www.xlogics.pl
-------------------------------------------------

[Ilja Preuß]

Hi Sam,

you might want to take a look at the "Adventures in C#" series:
http://www.xprogramming.com/xpmag/acsIndex.htm

Hope this helps,

Ilja

[Sam Jost]

phlip_cpp@yahoo.com (Phlip) schrieb:
*looks astonished* [...]I'm wondering if those classes gave you any benefit that I missed.I'm also wondering if C# (and the Java before it) are so wonderfulthey force all those extras just to test.

*laughs* I didnt use this set-up because it is the only way, but
because it was the first way I found documentation about.
Neither C# nor Java force anyone to use this approach.
To make your tests work you will have to make most of the controls and stuff in your form public instead of the normal private, or is there a way around this?Why?

Why what? Why make it public, or why use some other way (someone else
further down the thread had a way not to make them public by
inheriting from the form so he can access the details.
Next, while programming a GUI we often want to look at its intermediatestate. So I have a commented-out line that would have called 'Show' in Modalmode. It's Modal so we block all the other tests until we are finishedlooking at the window. Another idea would be to put the location out of sight, to a testing location where it does pop up but never be seen (like -10000/-10000).On AmigaOS, calling CreateWindow creates a window. It's there beforethe function returns. In this case, I will investigate pushing thatwindow to a screen in the background.Keeping your fingers on the keyboard, and the editor up with thekeyboard focus, even while GUI tests run, is the ultimate goal!

Well, if I really want that I just setup a second computer to run the
test on a shared drive so I would only have to press space bar and it
will run the tests. So compiling and testing wont disturb my typing at
all.

But I know what you mean, the test must run automatic, without any
user interaction. And it must run during daily builds and any failures
must be notified to the programmer.

Sam

[Phlip]

Remi Samosiuk wrote:
protected void button_Click(object sender, EventArgs e) {

I admit I'm pestering this thread because that's simpler than starting to
learn C#, but...

Why can't we just make that click public? Then, no mocks.

--
Phlip
http://www.c2.com/cgi/wiki?TestFirstUserInterfaces

[Remi Samosiuk]

"Phlip" <phlip_cpp@yahoo.com> wrote in message
news:Q1UOa.585$et.69@newssvr33.news.prodigy.com... Remi Samosiuk wrote: protected void button_Click(object sender, EventArgs e) { I admit I'm pestering this thread because that's simpler than starting to learn C#, but... Why can't we just make that click public? Then, no mocks. -- Phlip http://www.c2.com/cgi/wiki?TestFirstUserInterfaces

Because this makes public almost every method in class just because I want
to test it.
I don't think it's a good idea, especially if I write control that should
give only functionality that is needed by it's user (clas that uses it), not
internal methods.

Regards
Remi Samosiuk

Java & C# developer (MCP)
-------------------------------------------------
XLogics Polska
email: r.samosiuk@xlogics.pl
email: seer@proton.if.uz.zgora.pl (private)
URL: www.xlogics.pl
-------------------------------------------------

[Andrew Wall]

"Phlip" <phlip_cpp@yahoo.com> wrote in message
news:QkKOa.505$P6.348@newssvr33.news.prodigy.com... Load frmMyForm frmMyForm.Initialize "my data" ' <-- public method myDataBase.setSomeField("") frmMyForm.Submit_Click ' <-- pretend to click on a button I have trouble with doing this on at least two counts: 1) Submit_click() is private to the form, unless you go round and change these events to public Well, that's why VB lets you edit the source of its forms. Sometimes. 2) The whole of a form is private to a dll. (I use the 'Test Project references ActiveX DLL' idiom to seperate the tests from the code being tested.) I don't. I use the idiom "when you run in the IDE, it's test mode, when
you compile, it's release mode". But I have not cracked any of the standard test-runners yet. All my testing, so far, is in-module, using only Debug.Assert and such.
I couldn't work out how to use the existing vbUnit, so I wrote my own.
How do you make VB6 differentiate between IDE running and compiled running?
Also, do you have test cases written in VB6?
In theory - again from first principles - the ideal is you can keep typing during the 1/3rd second the tests run. So the ideal is you reduce as much
as possible any excuse not to run the tests. This removes any possible impediment to flow.
So what is it that you are typing during the test runs?


--
Andrew Wall

[Phlip]

> > > protected void button_Click(object sender, EventArgs e) {
Why can't we just make that click public? Then, no mocks.
Because this makes public almost every method in class just because I want to test it.

But end-users (the public at large) can already click on your button.
It's already never truly private.

If 'button' were public, can the test code call button.Click()
instead? (The way it can out of JavaScript inside DOM inside HTML
inside a Web browser?)
I don't think it's a good idea, especially if I write control that should give only functionality that is needed by it's user (clas that uses it), not internal methods.

Testing makes a few more things public than we are familiar with. But
not everything.

--
Phlip
http://www.greencheese.org/IneedAterabyte
-- Have a :-) day --

[David Lightstone]

"Laurent Bossavit" <laurent.ng@bossavit.com> wrote in message
news:MPG.1976ab98ba994b349896ba@news.noos.fr... Testing makes a few more things public than we are familiar with. But not everything. What testing makes public is what should be public. I call this the Principle of Legitimate Curiosity. Google "legitimate curiosity" (for some reason Google thinks my site is the most relevant hit for the phrase) or go directly to the source: http://bossavit.com/thoughts/archives/000040.html

when a macro can be used to allow you to configure whether something is
private or public, delayed binding can be exploited.

[Sam Jost]

"Andrew Wall" <ajwall@geocities.nospam.com> wrote:
"Phlip" <phlip_cpp@yahoo.com> wrote: I don't. I use the idiom "when you run in the IDE, it's test mode, whenyou compile, it's release mode". But I have not cracked any of the standard test-runners yet. All my testing, so far, is in-module, using only Debug.Assert and such.I couldn't work out how to use the existing vbUnit, so I wrote my own.How do you make VB6 differentiate between IDE running and compiled running?Also, do you have test cases written in VB6?

My test´s are set up in a way so I can run them with release and debug
code without having to change any compiler switch and without
rebuilding the code to distinguish between testing and publishing
code.
So I can use the NUnit as addin, command line, gui and release from
the very same code, even without having to ship the nunit-dll or
something.

I thought running the tests on the shipping code was important, so I
took care about this, and it wasnt even complicated.


If anyone is interested in the project setup, I'm just in the progress
of making a small TDD project with c# for myself that I can put
somewhere to download.

Sam

[Sam Jost]

"Remi Samosiuk" <seer@proton.if.uz.zgora.pl> wrote:
"Sam Jost" <sam.jost@b-soft.de> wrote:Unfortunately I have some bad news for you :-(I tried to programming with TDD in C#, but have problems with GUI anddatabase testing.First (like you) i tried to use MVC approach, but have more problems withthat then solutions.Next I use simple trick (but it takes me month to discover it - heh)public class MyForm{...protected void button_Click(object sender, EventArgs e){...}...}public class MockForm : MyForm{public void InvokeButtonClick(){ button_Click(this, EventArgs.Empty);}}And later in test you can just call InvokeButtonClick().Simple, isn't it :-)

This made me think of yet another way to do this with nunit:

[TestFixture]
public class TestMyForm:MyForm
{
[Test] public void MyFirstTest()
{
// Test whatever you want, you can even Show() the
// form here and test!
}
}

I had a real problem thinking up a test to check what my demo program
shows onscreen, but this morning I had an idea when I looked up
bitmaps: I will try and have a method painting whatever my window
shall show into a MetaFile and try to check if the MetaFile contains
what I expect of it, and have the OnPaint() just show the MetaFile so
the untested part will be very small,
(I might even give the OnPaint a MetaFile to paint all client blue and
check a few pixel if it did succeed, so even OnPaint could be checked
- gotta try this today)
Generally I test only when I can, and have one big problem.Everywhere where I read about TDD, autor write example with something like10.30: Start to write test for something10.33: It failed10.35: Done, I have green light.And when I read It, I think that I'm stupid or something, because it takesme usually 15 or 30 minutes to write a test(because I must write mock classor mock method, or usually I just don't know how to test something)

Well, I think 15-30 minutes is not bad, I hope to get there someday -
right now it does take me at least a night to think up a test for most
stuff.

Sam [heading off to write some tests]

[Remi Samosiuk]

"Sam Jost" <sam.jost@b-soft.de> wrote in message
news:tg5qgvse3d3c5rqal3dhbnc28enrgrvu22@4ax.com...
Well, I think 15-30 minutes is not bad, I hope to get there someday - right now it does take me at least a night to think up a test for most stuff. Sam [heading off to write some tests]

My problem is that in my firm I'm the only one who is interested in TDD.
Worse is that, because writing tests takes me so long I have the same
results as others - I talk about time and code quality.

So the question is: Is TDD really better then conventional ad-hoc
programming ??

[Sam Jost]

"Remi Samosiuk" <seer@proton.if.uz.zgora.pl> wrote:
"Sam Jost" <sam.jost@b-soft.de> wrote: Well, I think 15-30 minutes is not bad, I hope to get there someday - right now it does take me at least a night to think up a test for most stuff. Sam [heading off to write some tests]My problem is that in my firm I'm the only one who is interested in TDD.Worse is that, because writing tests takes me so long I have the sameresults as others - I talk about time and code quality.

Well, same here, thats why I took a small side project one
of my customers requested to practise TDD on. No others
work with this so I can take all the time I need to learn TDD
with it.
So the question is: Is TDD really better then conventional ad-hocprogramming ??

I took up this project to answer a very similar question:

is TDD really better then conventional ad-hoc programming _for me_??

Because as always answers that fit for one person need not be the
right answers for everyone else. And for learning TDD, as for learning
anything, it takes me a lot more time than using my old approach at my
first attempts.

So, for now I was not able to answer the question for myself, but I am
stubborn and still working on it. I would suggest that you dont take a
project with a tight schedule for learning, I threw my project away
four or five times over by now (well, I just dubbed my earlier
attempts 'prototypes for customer acceptance' so it does not feel so
much like working for naught)


You must see for yourself how much time you want to devote into
learning if TDD is good for you and you yourself must say if it is
worth the effort or not _for you_.

I for myself already devoted my evenings for quite a few weeks for
now, and I am sure I will sacrifice a lot more of my free time to be
able to draw a conclusion about TDD for myself.

And depending on my conclusion I might try and introduce my company to
TDD, but since we got a lot of old code this wont happen overnight
anyway so I am not in a hurry.

so I fear no one can help you with your question.
Sam

[Phlip]

> My problem is that in my firm I'm the only one who is interested in TDD. Worse is that, because writing tests takes me so long I have the same results as others - I talk about time and code quality. So the question is: Is TDD really better then conventional ad-hoc programming ??

In a non-XP shop, I alternate between evangelicizing XP and keeping it a
secret.

Shops that encourage heroism then give me the hardest projects.

TDD, and relentless test-last, allow me to whack each one very flat very
soon.

So, my absurdly high velocity and low bug rate show up on radars, even if
nobody's collecting formal metrics.

--
Phlip
http://www.c2.com/cgi/wiki?TestFirstUserInterfaces

[Sam Jost]

"Remi Samosiuk" <seer@proton.if.uz.zgora.pl> wrote:
For now I play with TDD from something like half a year. Usually for oneproject at home, for my brother.But also at work I try to use it.It looks like this:- I write a new specilized class/component using TDD and it works fine.- Then someone in the company want to add some future to this code, so he doit.- After some time, when I got back to that code I run tests, and half ofthem are failure.

There is one thing I already do that you had missed: I have a batch
to check out and rebuild each and every piece of source I did and to
run all tests, reporting failure to me by email.
This script runs at least once a day, so I notice someone breaking
my source or tests quite fast - that wont keep the tests from being
broken but you might notice the break earlier.

But I have yet to come to the point where I try and impose test on
others, so I cant really feel your pain yet (and I think if TDD is
worth it I will find a way to get our team to at least keep the
existing tests working)
One positive thing is that while I play with XP, I learn what isRefactoring.It helps me much to know (in the scientific like way) how to redesign thecode.


Oh, I did refactor loads, for years now. Always got me into trouble
now and then 'cause I broke a thing, but it kept my code cleaner, and
it was always worth the trouble for me.

Another thing, I was successful in making GUI-tests with Metafiles,
and I even found a way to test moving around and resizing my Form with
mouse emulation, very nice!

Sam

[Phlip]

Remi Samosiuk wrote:
Question :-) What are you do, when someone in the company change your tested code and after some time when you run tests you see that some of the failed ??

I do daily builds, as another poster replied.

Some of the tests get a CPPUNIT_DISABLED. So most of them at least
smoke-test the feature.

My colleagues see all the CPPUNIT_DISABLEDs as evidence this TDD thing is
not working.

So they continue to run their debuggers.

--
Phlip
http://www.c2.com/cgi/wiki?TestFirstUserInterfaces

[Laurent Bossavit]

> What are you do, when someone in the company change your tested code and after some time when you run tests you see that some of the failed ??

Fine them a dollar for breaking the build. For repeat offenders, cutting
off fingers should work well, up until the ninth or tenth occurrence.

[Remi Samosiuk]

"Laurent Bossavit" <laurent.ng@bossavit.com> wrote in message
news:MPG.1978d8447429ff529896bd@news.noos.fr... What are you do, when someone in the company change your tested code and after some time when you run tests you see that some of the failed ?? Fine them a dollar for breaking the build. For repeat offenders, cutting off fingers should work well, up until the ninth or tenth occurrence.

he he :-)
nice and extreme

[Code Like Hell]

"Phlip" <phlip_cpp@yahoo.com> wrote in message news:<sesPa.235$RO5.51@newssvr16.news.prodigy.com>... My problem is that in my firm I'm the only one who is interested in TDD. Worse is that, because writing tests takes me so long I have the same results as others - I talk about time and code quality. So the question is: Is TDD really better then conventional ad-hoc programming ?? In a non-XP shop, I alternate between evangelicizing XP and keeping it a secret. Shops that encourage heroism then give me the hardest projects. TDD, and relentless test-last, allow me to whack each one very flat very soon. So, my absurdly high velocity and low bug rate show up on radars, even if nobody's collecting formal metrics.

What was your rate like before TDD? Wasn't the practice just the
same tiny steps plus large risky chunks of code re-organization.
Basically the same thing. What TDD gets rid of is the risk associated
with trusting that your programmers have enough focus left to hold all
the details needed to execute the big risky chunk. So TDD introduces
risk control on the process that was already there, for a price.
That's the piece to sell. Right?

[Mike Smith]

Phlip wrote: TDD, and relentless test-last, allow me to whack each one very flat very soon.

"Test-last"?

--
Mike Smith

[Christophe Thibaut]

Question :-) What are you do, when someone in the company change your tested code and after some time when you run tests you see that some of the failed ??

What are you to do when developers change the user interface without
telling the guys who write the manuals ?

And when developers decide to add a cool feature without involving
manager nor customers ?

Your tests are part of the project. They change the code, they make the
tests pass. In XP, collective code ownership (the right for others to
change your code) is supported by developer tests that must pass all the
time. So "some tests failing after some time" does not happen.

In non XP, it may be harder to teach your colleagues how they have to
treat you. Either the specs are changing and no one bothered to inform
you, either the specs are still the same and the developers don't care
at all about product quality. In both cases, your process is sick.
For me this usually ends up with fixing the tests, because code was done well by someone. Just the idea of how this tested class was used changed. And I don't think it makes sense to waste time, just for fixing tests which someone breaks.

Unless you want to know if the code is suitable for a release. --ct

[Phlip]

Mike Smith wrote:
Phlip wrote: TDD, and relentless test-last, allow me to whack each one very flat very soon. "Test-last"?

Adding tests to (other's) legacy code. Meaning pretending one occupies the
QC role, but without any clout at all.

--
Phlip
http://www.c2.com/cgi/wiki?TestFirstUserInterfaces

[Tom Plunket]

SUPER KOOL 223 wrote:
What was your rate like before TDD? Wasn't the practice just the same tiny steps plus large risky chunks of code re-organization. Basically the same thing. What TDD gets rid of is the risk associated with trusting that your programmers have enough focus left to hold all the details needed to execute the big risky chunk. So TDD introduces risk control on the process that was already there, for a price. That's the piece to sell. Right?

What's the "for a price"?

In my experience, the TDD "price" is limited to more source
files. Development doesn't take any longer, and you spend less
time in the debugger. Net win in my view; disk space is cheap
and programmer time is expensive.

Oh yeah, and the code "just works." :)

-tom!

[Dave Farley]

In article <n76qgvs0hfbhnsa6d4l1tef1b7hn4hlc18@4ax.com>,
Sam Jost <sam.jost@b-soft.de> wrote:
But protected and public is the same in the end - if anyone wants to use a protected call they can just inherit a class and use it, it does not protect from anything. Of course with nunit Tests can be put into the class itself, but that would bind the nunit-testing-framework to your shipping code, a thing I would not like very much.

Of course in C# you also have the option of 'internal'. This limits the
visibility to code in the same assembly, I think it is called 'friend'
in VB.

So if you compile your tests into the same assembly you can retain the
encapsulation you want and get the visibility you need.

Dave

[Sam Jost]

Dave Farley <dave-farley@comcast.net> wrote:
Sam Jost <sam.jost@b-soft.de> wrote: But protected and public is the same in the end - if anyone wants to use a protected call they can just inherit a class and use it, it does not protect from anything. Of course with nunit Tests can be put into the class itself, but that would bind the nunit-testing-framework to your shipping code, a thing I would not like very much.Of course in C# you also have the option of 'internal'. This limits thevisibility to code in the same assembly, I think it is called 'friend'in VB.So if you compile your tests into the same assembly you can retain theencapsulation you want and get the visibility you need.

But wouldnt you have to either ship the tests with the product since
it is in the same assembly or use differently compiled assemblies for
shipping and testing?

Sam

[Code Like Hell]

Tom Plunket <tomas@fancy.org> wrote in message news:<g2l0hvg06bb2qmin2ntptgtq96aamsv9qd@4ax.com>... SUPER KOOL 223 wrote: What was your rate like before TDD? Wasn't the practice just the same tiny steps plus large risky chunks of code re-organization. Basically the same thing. What TDD gets rid of is the risk associated with trusting that your programmers have enough focus left to hold all the details needed to execute the big risky chunk. So TDD introduces risk control on the process that was already there, for a price. That's the piece to sell. Right? What's the "for a price"? In my experience, the TDD "price" is limited to more source files. Development doesn't take any longer, and you spend less time in the debugger. Net win in my view; disk space is cheap and programmer time is expensive. Oh yeah, and the code "just works." :) -tom!

Yeah, I know. I'm missing the point on purpose. I'm trying to find
a way to sell TDD to very experienced developers who think that there
is a price to maintaining a suite of tests associated with TDD. Of
course I don't get it.