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!

[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.co m>
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***@softcirc uits.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.co m>
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.co mwrote in message
news:11******** *************@m 79g2000cwm.goog legroups.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.co m>
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.co m (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*****@gregmi ller.netwrote:

The potential downside I see is that it encourages "developmen t 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.co m>
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.co mwrote in message
news:MP******** *************** *@msnews.micros oft.com...

The potential downside I see is that it encourages "developmen t 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.co m>
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.co mwrote in message
news:MP******** *************** *@msnews.micros oft.com...

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.co mwrote in message
news:MP******** *************** *@msnews.micros oft.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.

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.co mwrote in message
news:MP******** *************** *@msnews.micros oft.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