Edit and Continue

[Jeremy]

Is [Edit and Continue] a worthwhile feature?

I've lived just fine without it for years... don't see much value in using
it. Am I missing something?

Thanks!

[Jonathan Wood]

Why not?

While debugging your code, you might see a line you want to change before
executing it. You can make the change and restart the program, or just edit
and continue. Which would you prefer?

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

"Jeremy" <[e-mail] in message
news:OJ**************@TK2MSFTNGP04.phx.gbl...

Is [Edit and Continue] a worthwhile feature?

I've lived just fine without it for years... don't see much value in using
it. Am I missing something?

Thanks!

[Jeremy]

My prior experience with Edit and Continue (vb6, vba, etc) is that it's a
feature that, IF it were to function as advertised, might prove useful. But
things would periodically go wrong - thereby wasting much more time than the
feature was intended to save. Furthermore, assuming that it now "works as
advertised" it seems that changing a line of code while the application is
running might cause unknown (even unpredictable) conseqeunces.

You can see that I'm reluctant to try it again based on the considerations
given above. But rather than simply dismissing it, I'm wondering if there is
some aspect of [Edit and Continue] that you more experienced developers
conclude makes it a must-have feature. Do any of you use it "all the time"
or as a matter of course? Or do most of you prefer to not use it?

Thanks.
"Jonathan Wood" <jw***@softcircuits.comwrote in message
news:ey**************@TK2MSFTNGP05.phx.gbl...

Why not?

While debugging your code, you might see a line you want to change before
executing it. You can make the change and restart the program, or just
edit and continue. Which would you prefer?

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

"Jeremy" <[e-mail] in message
news:OJ**************@TK2MSFTNGP04.phx.gbl...

>Is [Edit and Continue] a worthwhile feature?

I've lived just fine without it for years... don't see much value in
using it. Am I missing something?

Thanks!

[Michael C]

"Jeremy" <[e-mail] in message
news:OJ**************@TK2MSFTNGP04.phx.gbl...

Is [Edit and Continue] a worthwhile feature?

I've lived just fine without it for years... don't see much value in using
it. Am I missing something?

It's just a time saving feature in my opinion, if you notice a mistake in
your code then you can change it without having to restart your app. This is
especially useful if it took a long time to get to the point your code is
at, eg at the end of a long import.

You're going to get replies from people who never need this feature because
they never make mistakes and always check their code before running it and
it works perfectly first time every time. But for those not living in
newsgroup fantasy land it is a very useful feature (not that I've got vs2005
but I'm using visual basic 6 on 1 project).

>
Thanks!

[Michael C]

"Jeremy" <[e-mail] in message
news:u$**************@TK2MSFTNGP03.phx.gbl...

My prior experience with Edit and Continue (vb6, vba, etc) is that it's a
feature that, IF it were to function as advertised, might prove useful.
But things would periodically go wrong - thereby wasting much more time
than the feature was intended to save.

The feature works pretty much perfectly in vb6, I don't know where you're
getting the idea that it doesn't work as advertised. It does require some
understanding of what is going on.

Furthermore, assuming that it now "works as advertised" it seems that
changing a line of code while the application is running might cause
unknown (even unpredictable) conseqeunces.

The usual situation is that you get an error, fix a simple mistake and
continue, but getting the error might cause some side effects. You just need
to take this into account but it's rarely a problem.

Michael

[Jonathan Wood]

I very rarely use it. But on those rare occasions, it can be nice. But,
frankly, I just don't see any downside to it.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

"Jeremy" <[e-mail] in message
news:u$**************@TK2MSFTNGP03.phx.gbl...

My prior experience with Edit and Continue (vb6, vba, etc) is that it's a
feature that, IF it were to function as advertised, might prove useful.
But things would periodically go wrong - thereby wasting much more time
than the feature was intended to save. Furthermore, assuming that it now
"works as advertised" it seems that changing a line of code while the
application is running might cause unknown (even unpredictable)
conseqeunces.

You can see that I'm reluctant to try it again based on the considerations
given above. But rather than simply dismissing it, I'm wondering if there
is some aspect of [Edit and Continue] that you more experienced developers
conclude makes it a must-have feature. Do any of you use it "all the time"
or as a matter of course? Or do most of you prefer to not use it?

Thanks.
"Jonathan Wood" <jw***@softcircuits.comwrote in message
news:ey**************@TK2MSFTNGP05.phx.gbl...

>Why not?

While debugging your code, you might see a line you want to change before
executing it. You can make the change and restart the program, or just
edit and continue. Which would you prefer?

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

"Jeremy" <[e-mail] in message
news:OJ**************@TK2MSFTNGP04.phx.gbl...

>>Is [Edit and Continue] a worthwhile feature?

I've lived just fine without it for years... don't see much value in
using it. Am I missing something?

Thanks!

[Greg Miller]

On Tue, 18 Jul 2006 19:08:49 -0700, "Jeremy" <[e-mail]:

>But things would periodically go wrong - thereby wasting much more time than
the feature was intended to save. Furthermore, assuming that it now "works as
advertised" it seems that changing a line of code while the application is
running might cause unknown (even unpredictable) conseqeunces.

I'm curious as to what types of problems you ran into.

[Jon Skeet [C# MVP]]

Jonathan Wood <jw***@softcircuits.comwrote:

Why not?

While debugging your code, you might see a line you want to change before
executing it. You can make the change and restart the program, or just edit
and continue. Which would you prefer?

Restart the program - otherwise I can't be sure that my change won't
have affected anything I've already done.

Of course, with a good battery of unit tests, "restart the program"
actually means "rerun the test" which I'd be doing anyway.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Jonathan Wood <jw***@softcircuits.comwrote:

I very rarely use it. But on those rare occasions, it can be nice. But,
frankly, I just don't see any downside to it.

The potential downside I see is that it encourages "development by
tinkering" - fix this particular problem, but don't bother checking
that nothing else is broken. I believe there are developers who write
more code in the debugger than not.

Now, this could be a myth, and it can certainly be avoided just by
being disciplined about when you use it. I *can* see E&C being useful
when trying different ways of presenting a UI - but I wouldn't want to
use it for fixing bugs.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Steven Nagy]

I agree. I think there is a possibility that it can breed complacency.
I think it can be used in moderation, but as Jon said, only for small
UI or similar situations. You don't want to rely on E&C. Its good that
its been absent for a few years, and I personally don't use it at all.

Jon, got any really good resources on unit testing in .NET ?
They're going to push Nunit on us at work and I want to be completely
prepared.
I have never before developed from a test-driven approach. I understand
the basic concepts of writing testable methods, but only the basics
mind you.
I'm sure there are lots of resources available that a Google would
find, but I want to know what YOU recommend.

Cheers,
Steven
Jon wrote:

Jonathan Wood <jw***@softcircuits.comwrote:

Why not?

While debugging your code, you might see a line you want to change before
executing it. You can make the change and restart the program, or just edit
and continue. Which would you prefer?

Restart the program - otherwise I can't be sure that my change won't
have affected anything I've already done.

Of course, with a good battery of unit tests, "restart the program"
actually means "rerun the test" which I'd be doing anyway.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Michael C <no****@nospam.comwrote:

<snip>

You're going to get replies from people who never need this feature because
they never make mistakes and always check their code before running it and
it works perfectly first time every time. But for those not living in
newsgroup fantasy land it is a very useful feature (not that I've got vs2005
but I'm using visual basic 6 on 1 project).

I've never seen anyone argue against E&C on those grounds. I *have*
seen people argue against E&C on the grounds that fixing a problem
while the program is running only shows that it's been fixed at that
particular point in time - the fix could easily have prevented you from
getting to the situation in the first place. Where possible (and with
some advanced techniques and appropriate design it's *almost* always
possible) unit tests can get you *repeatable* testing so that when a
bug is found, you can make sure it's fixed, stays fixed, and that the
fix doesn't adversely affect anything else. It's not a silver bullet,
but it's better (IMO) than using E&C and doing all testing manually.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Michael C]

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft.c om...

I've never seen anyone argue against E&C on those grounds.

I've seen plenty :-)

I *have*
seen people argue against E&C on the grounds that fixing a problem
while the program is running only shows that it's been fixed at that
particular point in time - the fix could easily have prevented you from
getting to the situation in the first place. Where possible (and with
some advanced techniques and appropriate design it's *almost* always
possible) unit tests can get you *repeatable* testing so that when a
bug is found, you can make sure it's fixed, stays fixed, and that the
fix doesn't adversely affect anything else. It's not a silver bullet,
but it's better (IMO) than using E&C and doing all testing manually.

What you're really saying is that because EC can be misused it should never
be used. Before you get to the point of unit testing you're going to have to
at least do some basic testing and EC can be very useful in those situation.

Michael

[Shawn Wildermuth (C# MVP)]

Hello Michael,

I have E&C turned on but it never seems to work. Does anyone know if this
is a limitation of ASP.NET (where I have tried to use it)?
Thanks,
Shawn Wildermuth
Speaker, Author and C# MVP
http://adoguy.com

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft.c om...

>I've never seen anyone argue against E&C on those grounds.

I've seen plenty :-)

>I *have*
seen people argue against E&C on the grounds that fixing a problem
while the program is running only shows that it's been fixed at that
particular point in time - the fix could easily have prevented you
from
getting to the situation in the first place. Where possible (and with
some advanced techniques and appropriate design it's *almost* always
possible) unit tests can get you *repeatable* testing so that when a
bug is found, you can make sure it's fixed, stays fixed, and that the
fix doesn't adversely affect anything else. It's not a silver bullet,
but it's better (IMO) than using E&C and doing all testing manually.

What you're really saying is that because EC can be misused it should
never be used. Before you get to the point of unit testing you're
going to have to at least do some basic testing and EC can be very
useful in those situation.

Michael

[Jon Skeet [C# MVP]]

Michael C wrote:

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft.c om...

I've never seen anyone argue against E&C on those grounds.

I've seen plenty :-)

Care to give any examples? I've been in this discussion plenty of
times, and never seen anyone claim they never write any bad code.

I *have*
seen people argue against E&C on the grounds that fixing a problem
while the program is running only shows that it's been fixed at that
particular point in time - the fix could easily have prevented you from
getting to the situation in the first place. Where possible (and with
some advanced techniques and appropriate design it's *almost* always
possible) unit tests can get you *repeatable* testing so that when a
bug is found, you can make sure it's fixed, stays fixed, and that the
fix doesn't adversely affect anything else. It's not a silver bullet,
but it's better (IMO) than using E&C and doing all testing manually.

What you're really saying is that because EC can be misused it should never
be used.

I'm saying that because E&C *is* misused, it's a dangerous feature to
have around.

Before you get to the point of unit testing you're going to have to
at least do some basic testing and EC can be very useful in those situation.

Um, no. I write my unit tests before I write my production code. Even
if I didn't do TDD, why would I do "basic" testing manually when I can
automate it and get the benefits again and again?

Jon

[Chris Nahr]

Given your signature you're probably talking about C# code? In that
case, I can assure you that E&C has never worked for me, either -- and
I'm using C# without ASP.NET...

On Wed, 19 Jul 2006 07:28:55 +0000 (UTC), Shawn Wildermuth (C# MVP)
<sw*********@newsgroup.nospamwrote:

>Hello Michael,

I have E&C turned on but it never seems to work. Does anyone know if this
is a limitation of ASP.NET (where I have tried to use it)?
Thanks,
Shawn Wildermuth
Speaker, Author and C# MVP
http://adoguy.com

--
http://www.kynosarges.de

[Michael C]

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:11**********************@s13g2000cwa.googlegr oups.com...

Care to give any examples? I've been in this discussion plenty of
times, and never seen anyone claim they never write any bad code.

This was when dot net came out how ever many years ago. Many claimed they
didn't use EC because they checked all their code before running it hence
had no bugs. A search of google should find something.

I'm saying that because E&C *is* misused, it's a dangerous feature to
have around.

Exactly, which is a pretty silly reason not to have a feature.

Um, no. I write my unit tests before I write my production code. Even
if I didn't do TDD, why would I do "basic" testing manually when I can
automate it and get the benefits again and again?

This is the sort of thing I call "newsgroup fantasy land", it's amazing to
watch as everyone all of a sudden starts doing everything perfectly to
support some particular arguement. I'd say 90% of developers or more would
never have done a unit test and 99% wouldn't use them for all their code.
The only time I do unit testing is for some critical components. If I was
writing device drivers then I would but I don't do that sort of work.

Michael

[Jon Skeet [C# MVP]]

Michael C wrote:

I'm saying that because E&C *is* misused, it's a dangerous feature to
have around.

Exactly, which is a pretty silly reason not to have a feature.

Well, I've found it a pretty compelling reason for C# not having
macros, templates (gaining the more limited but useful generics
instead), overloading of assignment operators, etc.

Um, no. I write my unit tests before I write my production code. Even
if I didn't do TDD, why would I do "basic" testing manually when I can
automate it and get the benefits again and again?

This is the sort of thing I call "newsgroup fantasy land", it's amazing to
watch as everyone all of a sudden starts doing everything perfectly to
support some particular arguement.

Are you claiming I *don't* practise TDD? Note that I'm not claiming I'm
perfect - quite the reverse. I write unit tests because I'm *not*
perfect - because I *do* have bugs in my code, and without unit tests
I'll miss a large proportion of them. (With unit tests, I'll still miss
a few - but much fewer.)

I'd say 90% of developers or more would
never have done a unit test and 99% wouldn't use them for all their code.

Then they should address that rather than using the crutch of E&C.
Using E&C addresses the symptom rather than the cause.

The only time I do unit testing is for some critical components. If I was
writing device drivers then I would but I don't do that sort of work.

Well, I've found it's improved the quality of both my design and
implementation, and saved me time in the long run. Why wouldn't I want
to do that on all code I plan to keep around for significant amounts of
time? (I don't personally unit test prototype code thoroughly, although
some unit tests are still worthwhile even then.)

Jon

[Michael C]

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:11**********************@75g2000cwc.googlegro ups.com...

Well, I've found it a pretty compelling reason for C# not having
macros, templates (gaining the more limited but useful generics
instead), overloading of assignment operators, etc.

I have to agree there, especially with macros. I'd also add VB6's With
operator to that :-) Although those features are stuck in code for ever.
You've got no way to tell if someone used EC by looking at their code.

Are you claiming I *don't* practise TDD? Note that I'm not claiming I'm
perfect - quite the reverse. I write unit tests because I'm *not*
perfect - because I *do* have bugs in my code, and without unit tests
I'll miss a large proportion of them. (With unit tests, I'll still miss
a few - but much fewer.)

I think you're exaggerating.

Then they should address that rather than using the crutch of E&C.
Using E&C addresses the symptom rather than the cause.

No it doesn't. It's just a convenience. Even if you write unit tests for
everything there has to be a point where you first run said code. At that
point you might notice you've written "DELECT * FROM" (as I often do) and
can easily fix it without a restart. I don't see how that is bad practice or
likely to cause problems. Even on the occasions I've written unit tests i've
still run the code manually beforehand, eg when writing a stored proc I'll
test it in query analyser first.

Well, I've found it's improved the quality of both my design and
implementation, and saved me time in the long run. Why wouldn't I want
to do that on all code I plan to keep around for significant amounts of
time? (I don't personally unit test prototype code thoroughly, although
some unit tests are still worthwhile even then.)

I just don't see how unit tests can apply to all of my code. How am I going
to test drag/drop with a unit test? In a lot of testing I think it needs a
person there to do it, especially business style database apps.

Michael

[Jon Skeet [C# MVP]]

Michael C wrote:

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:11**********************@75g2000cwc.googlegro ups.com...

Well, I've found it a pretty compelling reason for C# not having
macros, templates (gaining the more limited but useful generics
instead), overloading of assignment operators, etc.

I have to agree there, especially with macros. I'd also add VB6's With
operator to that :-) Although those features are stuck in code for ever.
You've got no way to tell if someone used EC by looking at their code.

Unless you see that changes haven't been planned so much as done on the
spur of the moment, to address a single point in time rather than a
more general issue. I'm not saying you'll always be able to point to
it, but if E&C is abused, I believe it will be at least somewhat
evident.

Are you claiming I *don't* practise TDD? Note that I'm not claiming I'm
perfect - quite the reverse. I write unit tests because I'm *not*
perfect - because I *do* have bugs in my code, and without unit tests
I'll miss a large proportion of them. (With unit tests, I'll still miss
a few - but much fewer.)

I think you're exaggerating.

You've never met me. You've never watched me code. Which part do you
think I'm exaggerating, and what evidence can you possibly have for
that belief?

Then they should address that rather than using the crutch of E&C.
Using E&C addresses the symptom rather than the cause.

No it doesn't. It's just a convenience. Even if you write unit tests for
everything there has to be a point where you first run said code. At that
point you might notice you've written "DELECT * FROM" (as I often do) and
can easily fix it without a restart. I don't see how that is bad practice or
likely to cause problems. Even on the occasions I've written unit tests i've
still run the code manually beforehand, eg when writing a stored proc I'll
test it in query analyser first.

The benefits of E&C are almost always stated in terms of not taking a
long time to get back to where you were. With unit tests, that time
just isn't there. It's very quick to just change the code and rerun the
unit tests. Given that you'd need to rerun the unit tests anyway to
give you overall confidence of the change, where's the benefit of using
E&C?

Well, I've found it's improved the quality of both my design and
implementation, and saved me time in the long run. Why wouldn't I want
to do that on all code I plan to keep around for significant amounts of
time? (I don't personally unit test prototype code thoroughly, although
some unit tests are still worthwhile even then.)

I just don't see how unit tests can apply to all of my code. How am I going
to test drag/drop with a unit test? In a lot of testing I think it needs a
person there to do it, especially business style database apps.

What part of database applications can't be unit tested? UI work is
indeed a lot harder to unit test, but that's only one (hopefully
well-separated) layer - and where logic is required in the presentation
layer, that can still be tested. As I think I said before, UI work
could possibly benefit from E&C, but if there is logic to be changed,
I'd still unit test that and make changes by rerunning the unit tests
rather than E&C.

Jon

[Jonathan Wood]

Jon,

>I very rarely use it. But on those rare occasions, it can be nice. But,
frankly, I just don't see any downside to it.

The potential downside I see is that it encourages "development by
tinkering" - fix this particular problem, but don't bother checking
that nothing else is broken. I believe there are developers who write
more code in the debugger than not.

Now, this could be a myth, and it can certainly be avoided just by
being disciplined about when you use it. I *can* see E&C being useful
when trying different ways of presenting a UI - but I wouldn't want to
use it for fixing bugs.

This assumes facts not in evidence.

I've been programming 20 years now and feel I know adaquately how to write
and test programs. Yet, I've just indicated I may on occasion use edit and
continue.

Should we eliminate pointers because someone without experience might abuse
them? I hardly see that some folks might abuse a feature as a downside to
having that feature.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

[Jonathan Wood]

Jon,

>While debugging your code, you might see a line you want to change before
executing it. You can make the change and restart the program, or just
edit
and continue. Which would you prefer?

Restart the program - otherwise I can't be sure that my change won't
have affected anything I've already done.

Your assumptions aside that saving time using Edit and Continue would mean I
would not do further testing, do you mean to suggest that you think I
couldn't come up with a single example where there would be no side effects
of changing one line in a program?

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

[Jon Skeet [C# MVP]]

Jonathan Wood <jw***@softcircuits.comwrote:

While debugging your code, you might see a line you want to change before
executing it. You can make the change and restart the program, or just
edit
and continue. Which would you prefer?

Restart the program - otherwise I can't be sure that my change won't
have affected anything I've already done.

Your assumptions aside that saving time using Edit and Continue would mean I
would not do further testing, do you mean to suggest that you think I
couldn't come up with a single example where there would be no side effects
of changing one line in a program?

I would rather have the unit tests all passing to tell me that that's
the case, rather than rely on my intuition and reasoning.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Jonathan Wood <jw***@softcircuits.comwrote:

I very rarely use it. But on those rare occasions, it can be nice. But,
frankly, I just don't see any downside to it.

The potential downside I see is that it encourages "development by
tinkering" - fix this particular problem, but don't bother checking
that nothing else is broken. I believe there are developers who write
more code in the debugger than not.

Now, this could be a myth, and it can certainly be avoided just by
being disciplined about when you use it. I *can* see E&C being useful
when trying different ways of presenting a UI - but I wouldn't want to
use it for fixing bugs.

This assumes facts not in evidence.

Well, I've heard people say how they do a large amount of their coding
in the debugger, so that counts as evidence to some extent.

I've been programming 20 years now and feel I know adaquately how to write
and test programs. Yet, I've just indicated I may on occasion use edit and
continue.

And I've said that for UI work it could very occasionally be useful -
but:

1) It must have taken time to develop - and I wish that time had been
spent improving the editor

2) A feature which can be useful occasionally but is often abused isn't
a good thing usually, IMO.

(I should say at this point: programming for 20 years doesn't
necesarily indicate anything about your or anyone else's programming
ability. It's quite possible to have a lot of experience and not have
learned anything from it - I've seen that happen. I'm *not* saying
that's the case here - just that your "20 years" bit doesn't really
mean anything as far as I'm concerned.)

Should we eliminate pointers because someone without experience might abuse
them? I hardly see that some folks might abuse a feature as a downside to
having that feature.

And yet we pretty much *have* eliminated pointers - or at least pointer
arithmetic. Their use is pretty restricted in C#, and doesn't exist at
all (unless things have changed recently) in VB.NET. Macros and
templates have gone in exactly the same way.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Alvin Bruney [MVP]]

It's no secret, based on past discussion, that Jon is steadfastly against
using a debugger and would prefer unit tests. However, I use both unit tests
and E&C and I'd rather have both, E&C before unit tests of course. I like to
step, jump to next statement, change variables etc. when I am satisfied with
this, I run my unit tests. And if it's friday end of day, I skip the unit
tests. period. Reason being, the unit tests and my E&C exploration performed
the same exercise.

For any developer who uses the debugger a lot, it is a must have feature. If
you don't use the debugger and prefer unit tests, I can see why you would
think less of it.

>1) It must have taken time to develop - and I wish that >time had been
spent improving the editor

I'm leary of thinly veiled attempts to discredit E&C while promoting unit
tests. like i said, i've used both and part of my job is to shove unit tests
down the throats of developers in the enterprise, but unit tests are not the
panacea that they are made out to be. neither is E&C by the way. both are
valid and should be used as appropriate.

--
________________________
Warm regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
Professional VSTO.NET - Wrox/Wiley
The O.W.C. Black Book with .NET
www.lulu.com/owc, Amazon
Blog: http://www.msmvps.com/blogs/alvin
-------------------------------------------------------
"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft.c om...

Jonathan Wood <jw***@softcircuits.comwrote:

>While debugging your code, you might see a line you want to change
before
executing it. You can make the change and restart the program, or just
edit
and continue. Which would you prefer?

Restart the program - otherwise I can't be sure that my change won't
have affected anything I've already done.

Your assumptions aside that saving time using Edit and Continue would
mean I
would not do further testing, do you mean to suggest that you think I
couldn't come up with a single example where there would be no side
effects
of changing one line in a program?

I would rather have the unit tests all passing to tell me that that's
the case, rather than rely on my intuition and reasoning.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jonathan Wood]

Jon,

Well, I've heard people say how they do a large amount of their coding
in the debugger, so that counts as evidence to some extent.

Well, please let me know when you hear it again. It's just about the
craziest thing I've ever heard.

And I've said that for UI work it could very occasionally be useful -
but:

And that's all I'm saying.

>Should we eliminate pointers because someone without experience might
abuse
them? I hardly see that some folks might abuse a feature as a downside to
having that feature.

And yet we pretty much *have* eliminated pointers - or at least pointer
arithmetic. Their use is pretty restricted in C#, and doesn't exist at
all (unless things have changed recently) in VB.NET. Macros and
templates have gone in exactly the same way.

Sorry, I thought I was in another group when I wrote that.

So then your argument is that we should eliminate all features that can be
abused?

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

[Alvin Bruney [MVP]]

>>I have E&C turned on but it never seems to work. Does anyone know if this

>>is a limitation of ASP.NET (where I have tried to use it)?

ya, that thing has never worked for me on either 03 or 05 on my laptop. in
fact i tried it today with an active x control and it promptly refused to
proceed. maybe i take a look at it tomorrow to see if i can get it up and
running. either that or unit tests. YUCK!

--
________________________
Warm regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
Professional VSTO.NET - Wrox/Wiley
The O.W.C. Black Book with .NET
www.lulu.com/owc, Amazon
Blog: http://www.msmvps.com/blogs/alvin
-------------------------------------------------------
"Chris Nahr" <ch************@kynosarges.dewrote in message
news:i2********************************@4ax.com...

Given your signature you're probably talking about C# code? In that
case, I can assure you that E&C has never worked for me, either -- and
I'm using C# without ASP.NET...

On Wed, 19 Jul 2006 07:28:55 +0000 (UTC), Shawn Wildermuth (C# MVP)
<sw*********@newsgroup.nospamwrote:

>>Hello Michael,

I have E&C turned on but it never seems to work. Does anyone know if this
is a limitation of ASP.NET (where I have tried to use it)?
Thanks,
Shawn Wildermuth
Speaker, Author and C# MVP
http://adoguy.com

--
http://www.kynosarges.de

[Michael C]

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft.c om...

Well, I've heard people say how they do a large amount of their coding
in the debugger, so that counts as evidence to some extent.

They're exaggerating. Although I suspect they mean they spend the largest
amount of their developer time working in the debugger.

And I've said that for UI work it could very occasionally be useful -
but:

1) It must have taken time to develop - and I wish that time had been
spent improving the editor

I prefer the time saving of e&c.

2) A feature which can be useful occasionally but is often abused isn't
a good thing usually, IMO.

How much the feature is abused is a matter of opinion. I've not once opened
up someone's code and said to myself "damn e&c programmer".

(I should say at this point: programming for 20 years doesn't
necesarily indicate anything about your or anyone else's programming
ability. It's quite possible to have a lot of experience and not have
learned anything from it - I've seen that happen. I'm *not* saying
that's the case here - just that your "20 years" bit doesn't really
mean anything as far as I'm concerned.)

I agree, quite often the 20+ year programmers are worse. I had one telling
me that referetial integrity was unnecessary and a waste of time and that 0
should be used to indicate null in fks.

And yet we pretty much *have* eliminated pointers - or at least pointer
arithmetic. Their use is pretty restricted in C#, and doesn't exist at
all (unless things have changed recently) in VB.NET. Macros and
templates have gone in exactly the same way.

I was just thinking that when I read Johnathan's post that maybe pointers
should be eliminated because they are abused.

Michael

[Michael C]

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:11*********************@m79g2000cwm.googlegro ups.com...

Unless you see that changes haven't been planned so much as done on the
spur of the moment, to address a single point in time rather than a
more general issue. I'm not saying you'll always be able to point to
it, but if E&C is abused, I believe it will be at least somewhat
evident.

I used e&c alot in vb6 simply because it was taking 2 minutes to stop and
start my project in vb6 because it was so large (the 2 minutes is not an
exaggeration, I timed it). If I need to make a change that e&c doesn't allow
then I'll stop the project. I'll only ever make changes that I would have
made otherwise. I don't see why I should suffer the loss of this great
feature because someone else might abuse it.

You've never met me. You've never watched me code. Which part do you
think I'm exaggerating, and what evidence can you possibly have for
that belief?

I just know newsgroups. In these arguements everyone always becomes perfect
as I said.

The benefits of E&C are almost always stated in terms of not taking a
long time to get back to where you were. With unit tests, that time
just isn't there. It's very quick to just change the code and rerun the
unit tests. Given that you'd need to rerun the unit tests anyway to
give you overall confidence of the change, where's the benefit of using
E&C?

*Maybe* the 1% of programmers who regularly do unit tests don't need e&c but
for us humans it's quite useful.

What part of database applications can't be unit tested?

I'd say it would be difficult to unit test the majority of the work I do.
However, this discussion is not about unit tests. The fact is most
developers don't unit test or don't unit test a good percentage of their
work. For these developers e&c is very useful.

Michael

[Michael C]

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft.c om...

The potential downside I see is that it encourages "development by
tinkering" - fix this particular problem, but don't bother checking
that nothing else is broken. I believe there are developers who write
more code in the debugger than not.

That is an entirely different issue really that has nothing to do with e&c.
Once 1 part of an app is written and is first run in a workable state it
needs to be tested and have bugs fixed. Some developers will spend 10
minutes doing the testing, other's could spend 10 days or more. What you're
saying is that somehow e&c makes developers tend towards the 10 minute end
of the scale?

Michael

[Greg Miller]

On Wed, 19 Jul 2006 06:52:12 +0100, Jon Skeet [C# MVP] <sk***@pobox.com>
wrote:

>The potential downside I see is that it encourages "development by
tinkering" - fix this particular problem, but don't bother checking
that nothing else is broken. I believe there are developers who write
more code in the debugger than not.

Anyone who writes bad code inside a debugger will write bad code
outside the debugger. I just recently read a blog entry (don't remember
where), but I really like the idea they put forward: "Why worry about
errors someone might make, let's concentrate on the errors we DO make."

[John B]

Alvin Bruney [MVP] wrote:
<...>

..I use both unit tests
and E&C and I'd rather have both, E&C before unit tests of course.

<...>

Now I'm sure I'm taking this out of context but are you saying you would
prefer E&C over a properly fleshed out suite of unit tests?
JB

[Jon Skeet [C# MVP]]

<"Alvin Bruney [MVP]" <www.lulu.com/owc>wrote:

It's no secret, based on past discussion, that Jon is steadfastly against
using a debugger and would prefer unit tests. However, I use both unit tests
and E&C and I'd rather have both, E&C before unit tests of course.

That rules out TDD to start with.

I like to step, jump to next statement, change variables etc. when I
am satisfied with this, I run my unit tests. And if it's friday end
of day, I skip the unit tests. period. Reason being, the unit tests
and my E&C exploration performed the same exercise.

That suggests you don't properly understand the benefits of unit
testing. If you don't have tests which can be rerun at a whim, you
don't have repeatability. At that point, you don't have the extra
confidence in making changes later on that unit tests give you. If I
take someone else's code and it's got an adequate amount of unit
testing around it, I can change it and be reasonably confident that I'm
not breaking anything so long as the unit tests still pass. If the
original author only did "E&C testing" I have no such confidence.

For any developer who uses the debugger a lot, it is a must have feature. If
you don't use the debugger and prefer unit tests, I can see why you would
think less of it.

Debugger != E&C. It's important to have a debugger, even though I tend
to think that if you need to use a debugger to find out what's going
on, that usually indicates that the code isn't as readable as it should
be. I always count it as a minor defeat when I need to use a debugger.

1) It must have taken time to develop - and I wish that >time had been
spent improving the editor

I'm leary of thinly veiled attempts to discredit E&C while promoting unit
tests. like i said, i've used both and part of my job is to shove unit tests
down the throats of developers in the enterprise, but unit tests are not the
panacea that they are made out to be. neither is E&C by the way. both are
valid and should be used as appropriate.

The fact that you are happy to ditch unit tests and lean on the E&C
crutch when you can't be bothered to do the job properly (as I would
see it) highlights the risk of E&C as far as I'm concerned.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Jonathan Wood <jw***@softcircuits.comwrote:

Well, I've heard people say how they do a large amount of their coding
in the debugger, so that counts as evidence to some extent.

Well, please let me know when you hear it again. It's just about the
craziest thing I've ever heard.

Sure.

Should we eliminate pointers because someone without experience might
abuse
them? I hardly see that some folks might abuse a feature as a downside to
having that feature.

And yet we pretty much *have* eliminated pointers - or at least pointer
arithmetic. Their use is pretty restricted in C#, and doesn't exist at
all (unless things have changed recently) in VB.NET. Macros and
templates have gone in exactly the same way.

Sorry, I thought I was in another group when I wrote that.

So then your argument is that we should eliminate all features that can be
abused?

Sometimes it's the right thing to do. You need to weigh up the
advantages of a feature vs the risk of abuse: how often it's likely to
be abused and the consequence of the abuse, also bearing in mind the
alternatives (such as unit testing) and how long it takes the feature
provider (MS) to implement the feature when they could be doing other
things. (It's no secret that I think the editor in VS.NET, even in
2005, is weaker than the Java editor in Eclipse. I'd rather have Open
Type and Open Resource dialogs than E&C...)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Michael C <no****@nospam.comwrote:

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:11*********************@m79g2000cwm.googlegro ups.com...

Unless you see that changes haven't been planned so much as done on the
spur of the moment, to address a single point in time rather than a
more general issue. I'm not saying you'll always be able to point to
it, but if E&C is abused, I believe it will be at least somewhat
evident.

I used e&c alot in vb6 simply because it was taking 2 minutes to stop and
start my project in vb6 because it was so large (the 2 minutes is not an
exaggeration, I timed it). If I need to make a change that e&c doesn't allow
then I'll stop the project. I'll only ever make changes that I would have
made otherwise. I don't see why I should suffer the loss of this great
feature because someone else might abuse it.

But don't you see how if you could have tested one piece of logic in
isolation, it wouldn't have taken 2 minutes to start? I'm unfamiliar
with the VB6 environment, so maybe it wouldn't have helped (and maybe
there isn't a decent unit testing framework available) but I'm certain
that that pain can be avoided in .NET.

You've never met me. You've never watched me code. Which part do you
think I'm exaggerating, and what evidence can you possibly have for
that belief?

I just know newsgroups. In these arguements everyone always becomes perfect
as I said.

And as I've already said, I use unit testing because I'm *not* perfect.

The benefits of E&C are almost always stated in terms of not taking a
long time to get back to where you were. With unit tests, that time
just isn't there. It's very quick to just change the code and rerun the
unit tests. Given that you'd need to rerun the unit tests anyway to
give you overall confidence of the change, where's the benefit of using
E&C?

*Maybe* the 1% of programmers who regularly do unit tests don't need e&c but
for us humans it's quite useful.

Those who use unit tests are admitting to start with that they're
human. Unit testing isn't nearly as hard as you're implying it is. Of
course, it's easier on green-field code than testing existing legacy
code, but there are well-documented techniques for lots of nasty
situations.

I'm no super-developer. I'm a human developer who does unit testing
wholeheartedly. Why is that so hard to accept?

What part of database applications can't be unit tested?

I'd say it would be difficult to unit test the majority of the work I do.
However, this discussion is not about unit tests.

I think they're very relevant though - if one feature makes another
almost obsolete, that makes it pretty relevant to the discussion.

The fact is most developers don't unit test or don't unit test a good
percentage of their work. For these developers e&c is very useful.

Perhaps if they hadn't been given the crutch of E&C, some of these
developers would have embraced unit testing earlier.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[John B]

Steven Nagy wrote:

I agree. I think there is a possibility that it can breed complacency.
I think it can be used in moderation, but as Jon said, only for small
UI or similar situations. You don't want to rely on E&C. Its good that
its been absent for a few years, and I personally don't use it at all.

Jon, got any really good resources on unit testing in .NET ?

<...>
Wrong John but I thought I would share some of my TDD resources anyway.
The bowling Game:
http://www.objectmentor.com/resource...easers/bowling
But Uncle Bob: http://www.butunclebob.com/ArticleS.UncleBob
More Uncle Bob: http://www.artima.com/weblogs/index....ogger=unclebob
And XProgramming.com (Ron Jeffries):
http://www.xprogramming.com/Blog/Pag...eedleOfInquiry
http://www.xprogramming.com/index.htm

Also check out the included tests in the NUnit suite as it is done Test
First (I presume).

HTH
JB

[Jon Skeet [C# MVP]]

Greg Miller <gm*****@gregmiller.netwrote:

The potential downside I see is that it encourages "development by
tinkering" - fix this particular problem, but don't bother checking
that nothing else is broken. I believe there are developers who write
more code in the debugger than not.

Anyone who writes bad code inside a debugger will write bad code
outside the debugger.

But perhaps not forever. Perhaps they'll write terrible unit tests to
start with - but they can improve.

I just recently read a blog entry (don't remember
where), but I really like the idea they put forward: "Why worry about
errors someone might make, let's concentrate on the errors we DO make."

I'd like to encourage others towards best practice, however.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Michael C <no****@nospam.comwrote:

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft.c om...

The potential downside I see is that it encourages "development by
tinkering" - fix this particular problem, but don't bother checking
that nothing else is broken. I believe there are developers who write
more code in the debugger than not.

That is an entirely different issue really that has nothing to do with e&c.
Once 1 part of an app is written and is first run in a workable state it
needs to be tested and have bugs fixed. Some developers will spend 10
minutes doing the testing, other's could spend 10 days or more. What you're
saying is that somehow e&c makes developers tend towards the 10 minute end
of the scale?

No - E&C encourages developers to fix the problem they're looking at
*this instant* without worrying about other issues. Unit testing
encourages developers to fix the problem they're looking at while
making sure they don't break anything else that was already working.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Michael C]

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft.c om...

No - E&C encourages developers to fix the problem they're looking at
*this instant* without worrying about other issues. Unit testing
encourages developers to fix the problem they're looking at while
making sure they don't break anything else that was already working.

How exactly? I run my code and it gives me an error that an sql statement is
incorrect. I'm going to fix the sql statement either way?

Michael

[Michael C]

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft.c om...

But don't you see how if you could have tested one piece of logic in
isolation, it wouldn't have taken 2 minutes to start? I'm unfamiliar
with the VB6 environment, so maybe it wouldn't have helped (and maybe
there isn't a decent unit testing framework available) but I'm certain
that that pain can be avoided in .NET.

There's only so much you can test outside the app. I'd imagine you do very
different work to me.

I think they're very relevant though - if one feature makes another
almost obsolete, that makes it pretty relevant to the discussion.

NOT IF NO ONE IS USING THAT FEATURE!!!!! Maybe object orientated databases
make relational database obsolete but no one is using them either. I know
"no one" is an exaggeration but most developers don't unit test.

Michael

[Jon Skeet [C# MVP]]

Michael C wrote:

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft.c om...

But don't you see how if you could have tested one piece of logic in
isolation, it wouldn't have taken 2 minutes to start? I'm unfamiliar
with the VB6 environment, so maybe it wouldn't have helped (and maybe
there isn't a decent unit testing framework available) but I'm certain
that that pain can be avoided in .NET.

There's only so much you can test outside the app. I'd imagine you do very
different work to me.

You may be surprised at how much can be unit tested reasonably easily
with the right tools available (most of which are free). I dare say we
do do different work, and there are certain areas which are indeed very
difficult to unit test, but I would hope that in most applications
those areas would be in the minority.

I think they're very relevant though - if one feature makes another
almost obsolete, that makes it pretty relevant to the discussion.

NOT IF NO ONE IS USING THAT FEATURE!!!!! Maybe object orientated databases
make relational database obsolete but no one is using them either. I know
"no one" is an exaggeration but most developers don't unit test.

I believe that situation is changing - certainly in the Java world,
unit testing is becoming more and more prevalent. Most of the
well-respected open source frameworks and libraries in Java come with a
comprehensive set of unit tests, for instance. I believe this situation
will be more and more the case in .NET as well - although it would have
been accelerated by Microsoft including unit testing in all editions of
VS.NET :(

However, that rate of progress will be further diminished by people
leaning on the crutch of E&C, I believe.

Jon

[Jon Skeet [C# MVP]]

Michael C wrote:

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft.c om...

No - E&C encourages developers to fix the problem they're looking at
*this instant* without worrying about other issues. Unit testing
encourages developers to fix the problem they're looking at while
making sure they don't break anything else that was already working.

How exactly? I run my code and it gives me an error that an sql statement is
incorrect. I'm going to fix the sql statement either way?

If that SQL statement has already been used in that run, you can't tell
whether you've broken what it's already done in E&C. You'll need to
rerun the whole application - making sure you hit every point which
could potentially use that SQL statement.

Doing that manually is time-consuming. Running a set of unit tests is
quick.

Jon

[Jon Skeet [C# MVP]]

Steven Nagy <le*********@hotmail.comwrote:

I agree. I think there is a possibility that it can breed complacency.
I think it can be used in moderation, but as Jon said, only for small
UI or similar situations. You don't want to rely on E&C. Its good that
its been absent for a few years, and I personally don't use it at all.

Jon, got any really good resources on unit testing in .NET ?
They're going to push Nunit on us at work and I want to be completely
prepared.
I have never before developed from a test-driven approach. I understand
the basic concepts of writing testable methods, but only the basics
mind you.
I'm sure there are lots of resources available that a Google would
find, but I want to know what YOU recommend.

Well, I use TestDriven.NET (unsurprisingly at www.testdriven.net) and
EasyMock.NET (www.easymock.net). However, the version of EasyMock.NET
I'm using is a completely rewritten one which I must get round to
committing back to CVS at some stage...

There's another mocking framework available at
http://www.ayende.com/projects/rhino-mocks.aspx

I haven't used it, but it's got better documentation etc than
EasyMock.NET, and it looks like the project is rather more lively too.
(That's my fault really, as the sole person who's actually done
anything on EasyMock.NET in the last 18 months.)

Mocking is really important (IMO) - without mocking, unit testing is
nightmarish, particularly when you have lots of collaborators. With
mocking (and IoC, preferrably), you tend to end up with a more modular
design with looser coupling.

There are a few coverage tools for .NET, but I haven't used any in the
last year, so any comments would almost certainly be way out of date.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Barry Kelly]

Jon Skeet [C# MVP] <sk***@pobox.comwrote:

Well, I use TestDriven.NET (unsurprisingly at www.testdriven.net) and
EasyMock.NET (www.easymock.net). However, the version of EasyMock.NET
I'm using is a completely rewritten one which I must get round to
committing back to CVS at some stage...

There's another mocking framework available at
http://www.ayende.com/projects/rhino-mocks.aspx

I haven't used it, but it's got better documentation etc than
EasyMock.NET, and it looks like the project is rather more lively too.
(That's my fault really, as the sole person who's actually done
anything on EasyMock.NET in the last 18 months.)

How do you deal with the problem that mocking requires modification to
the classes to support replaceability - e.g. descending from
MarshalByRefObject if a RealProxy technique is used, or using interfaces
/ delegates / virtual methods if Rhino Mocks is used?

How do you get rid of the modifications in release-mode code, or toggle
them safely, in order to avoid the downsides to interfaces & virtual
methods?

It seems like something that aspect-oriented programming or binary
rewriting would be useful for, but that would move what you're testing
further away from what you've actually written.

-- Barry

--
http://barrkel.blogspot.com/

[Michael D. Ober]

E&C is really useful when you are single stepping through the code and find
a one-off error in a loop counter. Fix the error and continue.

Mike Ober.

"Michael C" <no****@nospam.comwrote in message
news:Oj**************@TK2MSFTNGP03.phx.gbl...

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:11*********************@m79g2000cwm.googlegro ups.com...

Unless you see that changes haven't been planned so much as done on the
spur of the moment, to address a single point in time rather than a
more general issue. I'm not saying you'll always be able to point to
it, but if E&C is abused, I believe it will be at least somewhat
evident.

I used e&c alot in vb6 simply because it was taking 2 minutes to stop and
start my project in vb6 because it was so large (the 2 minutes is not an
exaggeration, I timed it). If I need to make a change that e&c doesn't

allow

then I'll stop the project. I'll only ever make changes that I would have
made otherwise. I don't see why I should suffer the loss of this great
feature because someone else might abuse it.

You've never met me. You've never watched me code. Which part do you
think I'm exaggerating, and what evidence can you possibly have for
that belief?

I just know newsgroups. In these arguements everyone always becomes

perfect

as I said.

The benefits of E&C are almost always stated in terms of not taking a
long time to get back to where you were. With unit tests, that time
just isn't there. It's very quick to just change the code and rerun the
unit tests. Given that you'd need to rerun the unit tests anyway to
give you overall confidence of the change, where's the benefit of using
E&C?

*Maybe* the 1% of programmers who regularly do unit tests don't need e&c

but

for us humans it's quite useful.

What part of database applications can't be unit tested?

I'd say it would be difficult to unit test the majority of the work I do.
However, this discussion is not about unit tests. The fact is most
developers don't unit test or don't unit test a good percentage of their
work. For these developers e&c is very useful.

Michael

[Alvin Bruney [MVP]]

>I believe that situation is changing
You are fooling yourself. For the most part, unit tests sit inside an
application and are never run until code is about to hit production. That is
closer to the truth than "the situation is changing". It's not.

Sure, there's a lot of talk about using unit tests regularly but the reality
is as soon as you turn your back, developers are back to coding habit. for
better or for worse.

The code that I have reviewed all have unit tests attached to them. I'd
wager a finger that during the development cycle these unit tests hardly
broke a sweat. And that's real world experience talking.

--
________________________
Warm regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
Professional VSTO.NET - Wrox/Wiley
The O.W.C. Black Book with .NET
www.lulu.com/owc, Amazon
Blog: http://www.msmvps.com/blogs/alvin
-------------------------------------------------------
"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:11**********************@s13g2000cwa.googlegr oups.com...

Michael C wrote:

>"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft. com...

But don't you see how if you could have tested one piece of logic in
isolation, it wouldn't have taken 2 minutes to start? I'm unfamiliar
with the VB6 environment, so maybe it wouldn't have helped (and maybe
there isn't a decent unit testing framework available) but I'm certain
that that pain can be avoided in .NET.

There's only so much you can test outside the app. I'd imagine you do
very
different work to me.

You may be surprised at how much can be unit tested reasonably easily
with the right tools available (most of which are free). I dare say we
do do different work, and there are certain areas which are indeed very
difficult to unit test, but I would hope that in most applications
those areas would be in the minority.

I think they're very relevant though - if one feature makes another
almost obsolete, that makes it pretty relevant to the discussion.

NOT IF NO ONE IS USING THAT FEATURE!!!!! Maybe object orientated
databases
make relational database obsolete but no one is using them either. I know
"no one" is an exaggeration but most developers don't unit test.

I believe that situation is changing - certainly in the Java world,
unit testing is becoming more and more prevalent. Most of the
well-respected open source frameworks and libraries in Java come with a
comprehensive set of unit tests, for instance. I believe this situation
will be more and more the case in .NET as well - although it would have
been accelerated by Microsoft including unit testing in all editions of
VS.NET :(

However, that rate of progress will be further diminished by people
leaning on the crutch of E&C, I believe.

Jon

[Michael C]

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:11**********************@m73g2000cwd.googlegr oups.com...

If that SQL statement has already been used in that run, you can't tell
whether you've broken what it's already done in E&C. You'll need to
rerun the whole application - making sure you hit every point which
could potentially use that SQL statement.

I've been fixing it in e&c in vb6 like that for 10 years and it rarely
causes a problem. I don't really see how it could if the sql string is
created on the line before it is used, eg

sql = "DELECT * FROM SomeTable"
rs.Open sql

if the rs.Open line failed then the recordset hasn't opened and going back 1
line is not going to cause any problem. Sure if the sql statement is created
in 1 place and passed into an object and that object goes through all sort
of initialisation then you might get a problem but I'm big and ugly enough
to know when not to use it.

Doing that manually is time-consuming. Running a set of unit tests is
quick.

I really don't see how unit tests are going to cover the full range of
testing. Most of the bugs I get reported from testing and user's wouldn't be
picked up by unit testing.

Michael

[Jon Skeet [C# MVP]]

Barry Kelly <ba***********@gmail.comwrote:

I haven't used it, but it's got better documentation etc than
EasyMock.NET, and it looks like the project is rather more lively too.
(That's my fault really, as the sole person who's actually done
anything on EasyMock.NET in the last 18 months.)

How do you deal with the problem that mocking requires modification to
the classes to support replaceability - e.g. descending from
MarshalByRefObject if a RealProxy technique is used, or using interfaces
/ delegates / virtual methods if Rhino Mocks is used?

When writing new classes, I use interfaces. Testing old code is
significantly harder.

How do you get rid of the modifications in release-mode code, or toggle
them safely, in order to avoid the downsides to interfaces & virtual
methods?

What downsides of interfaces are you thinking of?

It seems like something that aspect-oriented programming or binary
rewriting would be useful for, but that would move what you're testing
further away from what you've actually written.

True.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

<"Alvin Bruney [MVP]" <www.lulu.com/owc>wrote:

I believe that situation is changing

You are fooling yourself.

What makes you think you have so much better an idea of the state of
the industry than I have?

For the most part, unit tests sit inside an
application and are never run until code is about to hit production. That is
closer to the truth than "the situation is changing". It's not.

Sure, there's a lot of talk about using unit tests regularly but the reality
is as soon as you turn your back, developers are back to coding habit. for
better or for worse.

The code that I have reviewed all have unit tests attached to them. I'd
wager a finger that during the development cycle these unit tests hardly
broke a sweat. And that's real world experience talking.

So make running the tests part of the automated overnight build. That
way you *know* they're being executed, and you can see how much of the
system is being covered. High coverage certainly doesn't guarantee bug-
free code or even good tests, but it's a start.

When you say "and that's real world experience talking" you sound as if
you're accusing me of making it all up. I'm not. Where I work, we *do*
unit test - and we run them. If I'm given code to review, I review the
unit tests as well. If they're not adequate, I'll require them to be
improved. I make sure the unit tests pass before passing the code - and
I require that the existing unit tests haven't been broken.

None of this is particularly hard, so any talk of "only perfect
developers can do it" is nonsense.

If your real world experience is that unit tests aren't being used
properly, it's up to you to improve the situation - hold people to a
high standard, and over time things get better. Persuading people of
the benefits of unit testing can take a while (partly because the big
benefit is a long-term one) but it's far from impossible.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Michael C <no****@nospam.comwrote:

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:11**********************@m73g2000cwd.googlegr oups.com...

If that SQL statement has already been used in that run, you can't tell
whether you've broken what it's already done in E&C. You'll need to
rerun the whole application - making sure you hit every point which
could potentially use that SQL statement.

I've been fixing it in e&c in vb6 like that for 10 years and it rarely
causes a problem.

Or it causes problems you haven't noticed. There are such things as
subtle bugs.

I don't really see how it could if the sql string is
created on the line before it is used, eg

sql = "DELECT * FROM SomeTable"
rs.Open sql

if the rs.Open line failed then the recordset hasn't opened and going back 1
line is not going to cause any problem. Sure if the sql statement is created
in 1 place and passed into an object and that object goes through all sort
of initialisation then you might get a problem but I'm big and ugly enough
to know when not to use it.

That's a simplistic example - more realistic is the situation where an
off-by-one error is shown in a particular run. You fix it, but that
code has already been executed 100 times in that run, with different
parameters which didn't show the bug. Now your fix can show that the
101st time is okay, but it doesn't say anything about whether it would
have worked for the first 100 times.

Doing that manually is time-consuming. Running a set of unit tests is
quick.

I really don't see how unit tests are going to cover the full range of
testing. Most of the bugs I get reported from testing and user's wouldn't be
picked up by unit testing.

Without seeing the actual bugs, it's hard to answer that except to say
that my experience is the reverse - and indeed when a bug has been
reported, the first thing I try to do is write a unit test that fails
due to it. I can then fix it and be confident that the code will stay
fixed, as the unit test will start failing if the bug ever creeps back.

Now, are you really going to tell me that unit testing wouldn't have
picked up your SQL example above? Because if you are, that suggests you
really *aren't* unit testing as effectively as you can.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Michael C]

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft.c om...

Or it causes problems you haven't noticed. There are such things as
subtle bugs.

Possible but highly unlikely. The worst thing it's ever done is made me
chase bugs that don't exist and that's been something like 3 times in 10
years.

That's a simplistic example - more realistic is the situation where an

Actually it's a typical example. Most of the time the bug can be fixed on
the line the debugger is pointing to or the one previous. I'll always look
through the appropriate lines to make sure it's not likely to cause side
effects.

off-by-one error is shown in a particular run. You fix it, but that
code has already been executed 100 times in that run, with different
parameters which didn't show the bug. Now your fix can show that the
101st time is okay, but it doesn't say anything about whether it would
have worked for the first 100 times.

So you would obviously take caution in such a situation. It's no big deal.

Without seeing the actual bugs, it's hard to answer that except to say
that my experience is the reverse - and indeed when a bug has been
reported, the first thing I try to do is write a unit test that fails
due to it. I can then fix it and be confident that the code will stay
fixed, as the unit test will start failing if the bug ever creeps back.

The bugs are usually difficult to reproduce and would require the unit test
to have fairly intimate knowledge of the business rules. If it had such
knowledge it would really just be a duplication of the business rule and
probably have the same bug in the test anyway.

Now, are you really going to tell me that unit testing wouldn't have
picked up your SQL example above? Because if you are, that suggests you
really *aren't* unit testing as effectively as you can.

I never said that.

Michael