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!

[Jon Skeet [C# MVP]]

Michael C wrote:

"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?

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*********@ho tmail.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.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

[Barry Kelly]

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

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
MarshalByRefObj ect 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******** ******@TK2MSFTN GP03.phx.gbl...

"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.

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.co mwrote in message
news:11******** **************@ s13g2000cwa.goo glegroups.com.. .

Michael C wrote:

>"Jon Skeet [C# MVP]" <sk***@pobox.co mwrote in message
news:MP******* *************** **@msnews.micro soft.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.co mwrote in message
news:11******** **************@ m73g2000cwd.goo glegroups.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
MarshalByRefObj ect 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.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]]

<"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.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******** **************@ m73g2000cwd.goo glegroups.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.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...

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