c# 2004 (Whidbey)

[Alvin Bruney]

Re: c# 2004 (Whidbey)

I'm confused now.
What is the point of doing both unit tests and stepping thru a debugger then
(on corporate time that is)? What would one method uncover that the other
one won't since they are in fact doing the exact same thing - assuming that
you spent the day writing a unit test to examine every line of code (which
is feasible but very impractical). Seems like we all ought to go with Nial's
suggestion and forget about the debugger and just rely on unit tests to keep
the airplane from hitting the mountain.

Case in point. My function takes a date string examines it, returns a
formatted string or empty if the date is bogus. There are many ways to enter
bogus dates obviously. Would your unit test, generate every possible bogus
date? No? A subset of bogus dates maybe? Well you are flying blind hoping
that the date entered was a date your unit test actually used. Is it not
easier to flush out this bug by examining what the string looks like in a
debugger? It's now easy to tell how your function can handle it for every
possible case. Not the best case in point but sufficient to demonstrate what
I am thinking.

That mountain sure looks close to us now. wonder if the date string the
pilot entered was tested.

"Jon Skeet" <skeet@pobox.co m> wrote in message
news:MPG.199de0 a91916e09d98a2b 8@news.microsof t.com...[color=blue]
> Alvin Bruney <vapordan_spam_ me_not@hotmail_ no_spamhotmail. com> wrote:[color=green][color=darkred]
> > > That's true of everything - but I'd rather put effort into unit[/color][/color][/color]
testing[color=blue][color=green][color=darkred]
> > > properly than into stepping through code properly once.[/color]
> >
> > You missed the point. I didn't, or can't remember saying I wouldn't unit
> > test. In fact, I didn't say that! what i had a gripe with was Nial[/color][/color]
saying he[color=blue][color=green]
> > didn't step thru written code instead relying on unit tests to fish out
> > bugs. That is wrong and will always be wrong. Every line of written code
> > must be stepped thru in the debugger. There is no compromise on this.[/color][/color]
none[color=blue][color=green]
> > at all. You can unit test before after or during the process. I[/color][/color]
encourage[color=blue][color=green]
> > it.[/color]
>
> But unit testing *does* (or at least should) execute all the code,
> getting complete coverage. What does it matter whether or not that
> happens in a debugger?
>[color=green][color=darkred]
> > > Where did Niall say that someone *else* would be writing the unit
> > > tests? Typically it's the person writing the code who writes the unit
> > > tests in the first place.[/color]
> >
> > No, that's not even the recommended way.[/color]
>
> It is from everyone I've heard recommending unit testing...
>[color=green]
> > In my case, unit tests were prepared by the testing department.[/color]
>
> And that sounds like a lousy idea to me - and you've said it didn't
> work. In my experience, testing departments should be dealing much more
> with system tests than with unit tests. Unit tests are on a much lower
> level than I believe most testing departments should care about.
>[color=green]
> > We were made to participate in a one day
> > seminar by some expert who taught that this was the recommended way to
> > proceed. Hence it was an assumption on my part based on my experience.[/color]
>
> It sounds like your "expert" wasn't actually very expert at all. Just
> because he recommended something that doesn't work doesn't mean that
> things that *do* work aren't recommended by other people.
>
> --
> Jon Skeet - <skeet@pobox.co m>
> http://www.pobox.com/~skeet/
> If replying to the group, please do not mail me too[/color]

[Jon Skeet]

Re: c# 2004 (Whidbey)

Alvin Bruney <vapordan_spam_ me_not@hotmail_ no_spamhotmail. com> wrote:[color=blue]
> I'm confused now.
> What is the point of doing both unit tests and stepping thru a debugger then
> (on corporate time that is)?[/color]

I generally only step through in a debugger when I don't understand
what's going on - eg if there's a bug.
[color=blue]
> What would one method uncover that the other
> one won't since they are in fact doing the exact same thing - assuming that
> you spent the day writing a unit test to examine every line of code (which
> is feasible but very impractical).[/color]

In order to step through every line, you'd have to set up the
appropriate conditions in the first place. If you can set up those
conditions, unit test them - then you can do it repeatably.
[color=blue]
> Seems like we all ought to go with Nial's
> suggestion and forget about the debugger and just rely on unit tests to keep
> the airplane from hitting the mountain.[/color]

Forget about the debugger for stepping through code which you believe
to be correct. Keep it for code which isn't working how you expect it
to.
[color=blue]
> Case in point. My function takes a date string examines it, returns a
> formatted string or empty if the date is bogus. There are many ways to enter
> bogus dates obviously. Would your unit test, generate every possible bogus
> date? No?[/color]

No, nor would you step through in a debugger for every possible bogus
date. However, you can still make sure your unit test covers every line
of code.
[color=blue]
> A subset of bogus dates maybe? Well you are flying blind hoping
> that the date entered was a date your unit test actually used.[/color]

Likewise if you're stepping through the debugger.
[color=blue]
> Is it not
> easier to flush out this bug by examining what the string looks like in a
> debugger?[/color]

Only if you know in advance which string is actually a bug.
[color=blue]
> It's now easy to tell how your function can handle it for every
> possible case. Not the best case in point but sufficient to demonstrate what
> I am thinking.[/color]

I don't think it is, actually - you haven't really demonstrated a case
where stepping through in the debugger would have helped.
[color=blue]
> That mountain sure looks close to us now. wonder if the date string the
> pilot entered was tested.[/color]

Of course, you haven't actually given any evidence that your code is
safer than Niall's.

--
Jon Skeet - <skeet@pobox.co m>

http://www.pobox.com/~skeet/

If replying to the group, please do not mail me too

[Niall]

Re: c# 2004 (Whidbey)


"Alvin Bruney" <vapordan_spam_ me_not@hotmail_ no_spamhotmail. com> wrote in
message news:%236Tv7bcX DHA.1640@TK2MSF TNGP10.phx.gbl. ..[color=blue]
> What you are describing is XP programming? isn't it? So we are on the same
> track. I am yet to be convinced that this approach to programming is
> profitable, all things considered. Here is a link.
> http://www.extremeprogramming.org/. I think the gist of your argument was
> you would rather unit test than step thru your code. My response was no,
> that's wrong. you absolutely must step thru every line of code you write.[/color]
no[color=blue]
> excuses. sure go ahead and unit test all you want to, that's part of it as
> well - a large part too, but you seemed to not want to step thru written
> code.
>
> In addition, i think you went way off course by thinking that if you[/color]
changed[color=blue]
> line 10,428 in source code that you needed to step thru all previous lines
> of code. The assumption was you already stepped thru these lines of code
> when you first wrote them, you now need to step thru line 10,428 which is
> the line you just changed. Use unit tests to regression test the previous
> lines of code.[/color]

In this case, you need unit testing as you say. If you didn't have unit
testing, you'd have no idea whether the rest of the system still works after
you change your code. The thing is... if you're prepared to use unit testing
for ensuring the safety of the whole of the system when central code is
changed, why are you not prepared to use it to ensure the safety of the code
that you're actually changing. Ideally, if there's a bug, you should write a
test which fails because of the bug, and then fix it.

If you do this, you get three benefits. Firstly, you can be certain you
fixed the bug, because if you didn't, the test would fail. Secondly, you
make sure that if someone comes along and changes the code such that the bug
returns, then the test will catch that. So you've fixed the bug for now, but
also ensured it remains fixed in future. Thirdly, you get a documentation of
the bug in the forms of a new requirement (which was previously missing), so
you further define the specifications of your code.

Niall

[Niall]

Re: c# 2004 (Whidbey)


"Alvin Bruney" <vapordan_spam_ me_not@hotmail_ no_spamhotmail. com> wrote in
message news:ea6nllcXDH A.1748@TK2MSFTN GP12.phx.gbl...[color=blue]
> I thought he meant someone in the testing dept wrote the unit tests. This[/color]
is[color=blue]
> what we did at the last company I worked at. And it was perfectly useless,
> clumsy and required way too much co-ordination. It may work with 30 - 30
> programmers like what Nial is saying, but not 400 as in the last company i
> worked for.
>[/color]
....[color=blue][color=green]
> >
> > Where did Niall say that someone *else* would be writing the unit
> > tests? Typically it's the person writing the code who writes the unit
> > tests in the first place.[/color]
>
> No, that's not even the recommended way. In my case, unit tests were
> prepared by the testing department. We were made to participate in a one[/color]
day[color=blue]
> seminar by some expert who taught that this was the recommended way to
> proceed. Hence it was an assumption on my part based on my experience.[/color]

If this person giving the seminar was talking specifically about XP, then I
think he wasn't very expert, as Jon has said. The idea of unit testing in XP
seems to be that you use the tests to give you the requirements for your
code, helping you evolve the design, and you get automated testing for free.
The XP idea is that you are supposed to write the unit tests before you
write any of the actual code. They even go so far as to recommend you write
the test before it will even compile (because you haven't even declared the
actual function).

So... writing unit tests after you have written the code, and especially
getting someone who isn't involved in the coding of the original function to
write the tests afterward is a very bad thing. That person could have no
idea, or not enough of an idea of what you're doing, and hence not write
tests that fully cover your code. This is why the tests are more useful if
they come first: by writing the test, you then know what you're doing in the
function.

The only way I could see unit testing working when there is a coder (or
coders) and a tester who is completely uninvolved in the coding would be if
the tester is the one that knows what the function should be doing, and they
write the test for the coder as a specification before the coder begins
their work.

Niall

[Alvin Bruney]

Re: c# 2004 (Whidbey)

One final question. And this would be the final one.
You
actually
seriously
no jokingly
the-boss-is-not-over-your-shoulder-so-you-can-speak-freely

write unit tests before you start to write code?
write unit tests before you start to debug broken code?

if this is true you need a medal. plain and simple.
waiting for that serious reply.

PS. If it is any consolation Skeet doesn't do unit tests before he fires up
the debugger either. He says so on his website ;-)

"Niall" <asdf@me.com> wrote in message
news:eOYqoP6XDH A.1916@TK2MSFTN GP12.phx.gbl...[color=blue]
>
> "Jon Skeet" <skeet@pobox.co m> wrote in message
> news:MPG.199df5 b95993c8a198a2b 9@news.microsof t.com...[color=green]
> > Alvin Bruney <vapordan_spam_ me_not@hotmail_ no_spamhotmail. com> wrote:[color=darkred]
> > > What would one method uncover that the other
> > > one won't since they are in fact doing the exact same thing - assuming[/color][/color]
> that[color=green][color=darkred]
> > > you spent the day writing a unit test to examine every line of code[/color][/color]
> (which[color=green][color=darkred]
> > > is feasible but very impractical).[/color]
> >
> > In order to step through every line, you'd have to set up the
> > appropriate conditions in the first place. If you can set up those
> > conditions, unit test them - then you can do it repeatably.[/color]
>
> Exactly. If you're stepping through your code, and doing it thoroughly,
> you'd have to know what you'd expect to happen , and you'd have to know[/color]
what[color=blue]
> kind of cases are likely to cause problems. Basically, every time you're
> thinking to yourself something along the lines of "Right, if I set this to
> <x>, and then let that line run, it should go into here, and set that to
> <y>", you've just done exactly the same thing as you do when you write a
> unit test. You set up the condition, cause the code execution to happen,[/color]
and[color=blue]
> then make sure that the code executed with the expected result.
>
> So if you know all these conditions and checks used to ensure correct
> behaviour, why not write them down in code so that they are persistent.[/color]
That[color=blue]
> way you can gain the benefits from having documented the requirements, as
> well as repeatable testing that can be used by other people to prevent
> errors.
>
>
> As for the date example, I agree with what Jon has said. You can't test
> every possible input in debugging and unit testing, but in both cases, you
> can make sure that you cover all cases. So, hence, you run the same risks[/color]
of[color=blue]
> missing cases with both approaches. You could actually cover more cases[/color]
with[color=blue]
> the unit tests if you wanted to, because once you have written the test,[/color]
it[color=blue]
> only takes a fraction of a second to run. So you could test ten dates, a
> hundred dates, you could write a macro to generate assertions for testing[/color]
a[color=blue]
> thousand dates, if you really wanted. It would take forever to do that[/color]
while[color=blue]
> stepping through the code.
>[color=green]
> > Is it not easier to flush out this bug by examining what the string[/color][/color]
looks[color=blue]
> like in a debugger?
>
> How come it's easier to look at some text in the watch window and see if[/color]
it[color=blue]
> has the right value than to write an assertion that expects the value you
> would have been looking for in the watch window?
>
> With unit testing, you take the time to work through the function and get
> down the expected behaviours once only. In both unit testing and stepping
> through, you have to work out what behaviours you want to see. So it takes
> you a little longer to take that and write it down into a unit test.[/color]
Hence,[color=blue]
> on a pure time basis, if you only ever test a function once, it will
> probably take you less time to step through it. As soon as you test it the
> second time, the story is different. You have to re-step through[/color]
everything[color=blue]
> manually with the debugger, whereas you can just click Run with the unit
> tests.
>
> This only talks about the time taken to run the tests. I find that unit
> testing saves a lot of time in other places, such as design, because you[/color]
are[color=blue]
> generating your code to match a laid down set of specifications, and you[/color]
can[color=blue]
> always tell what specifications you are not properly meeting. It also[/color]
saves[color=blue]
> a lot of time in code maintenance because anyone can come through to fix a
> bug or add functionality and all the work you initially did to specify
> exactly how your code should work is still there. So you guarantee that[/color]
the[color=blue]
> next person does not overlook something that you spent the time to nut[/color]
out.[color=blue]
>
> I would agree with Jon when he says to leave the debugger for bugs. If you
> write good unit tests, they can cover your code as well or better than
> stepping through it manually. And you get all the benefits that come with
> the tests as well...
>
> Niall
>
>[/color]

[ncaHammer]

Re: c# 2004 (Whidbey)

"Alvin Bruney" <vapordan_spam_ me_not@hotmail_ no_spamhotmail. com> wrote in
message news:uSeimAFYDH A.2308@TK2MSFTN GP12.phx.gbl...[color=blue]
> write unit tests before you start to write code?
> write unit tests before you start to debug broken code?[/color]

yes, i do always

special with GUI stuff, i have a test suite which does vectorization and
checks for proper painting, so i can catch bugs such as improper
painting of a listview items etc (one other does face recognition too)

now i am writing a database test suite, i can estimate that a single test
with real data should finish 10 years from now, but that's ok, i am admit
it,
i am test suite addicted

Regards

ps. i have a bug in my app with the cursor shapes (once the mouse enter in
some graph objects bounds does not change to hand-cursor but to
wait-cursor), have you got any idea how can i write a test suite for it ?

[Niall]

Re: c# 2004 (Whidbey)

"Alvin Bruney" <vapordan_spam_ me_not@hotmail_ no_spamhotmail. com> wrote in
message news:uSeimAFYDH A.2308@TK2MSFTN GP12.phx.gbl...[color=blue]
> One final question. And this would be the final one.
> You
> actually
> seriously
> no jokingly
> the-boss-is-not-over-your-shoulder-so-you-can-speak-freely
>
> write unit tests before you start to write code?
> write unit tests before you start to debug broken code?[/color]

I can't say that I do it all the time. I do it mostly, but not always. In
the cases where I don't write the test first, it's usually because what I'm
doing is like a "spike" as seen in XP. If you don't know what that means,
it's just when you have an idea about something you want to do, and you're
having a quick test of the code to see what kind of shape the implementation
would take.

So if my manager comes to me and says that something should work
differently, and it's not obvious how to implement that, I'll have a think,
come up with an idea, and try it out. If it looks like that idea is going to
be the one I want to use, then I write the test for it, then go back and
clean up/finish off the implementation. This kind of approach may not be
appealing to those who have a passionate dislike of Edit and Continue :P

The one area I find it difficult, and not overly beneficial to test is
highly GUI dependent work. It can be a real pain to actually get the
information you need about your GUI object to be able to tell if it's
working as intended or not. So what we aim for is forms that have as little
code in them as possible, quite often no extra code on top of the designer
generated region. Then you can test the object that's underneath the form (a
business object/collection of them) as much as you like. If I do have to
write some code in the form that's non trivial, and cannot be moved
elsewhere, I do my best to set up a test for it. This still leaves a slight
gap in the unit testing, but the thinner you make your forms, the thinner
the gap.
[color=blue]
> if this is true you need a medal. plain and simple.
> waiting for that serious reply.
>
> PS. If it is any consolation Skeet doesn't do unit tests before he fires[/color]
up[color=blue]
> the debugger either. He says so on his website ;-)[/color]

I think unit tests are at their most beneficial when written first. However,
sometimes that's not how the mind (well, mine at least) works. Especially if
I'm making modifications to someone else's code, sometimes I want to have a
short mess around first to get a feel for how I want to do the work. But
before I get anything substantial done, I try to get a unit test down.

So my approach isn't perfect, but I doubt anyone's is :P

Niall

[Jon Skeet]

Re: c# 2004 (Whidbey)

Alvin Bruney <vapordan_spam_ me_not@hotmail_ no_spamhotmail. com> wrote:[color=blue]
> One final question. And this would be the final one.
> You
> actually
> seriously
> no jokingly
> the-boss-is-not-over-your-shoulder-so-you-can-speak-freely
>
> write unit tests before you start to write code?
> write unit tests before you start to debug broken code?
>
> if this is true you need a medal. plain and simple.
> waiting for that serious reply.
>
> PS. If it is any consolation Skeet doesn't do unit tests before he fires up
> the debugger either. He says so on his website ;-)[/color]

I rarely fire up the debugger at all. Usually when code is broken, I
fix it by adding a couple of trace elements or just by inspection.

I freely acknowledge that I don't use unit tests nearly as much as I
should. I wish I did. But then, do you really, seriously, no boss
involved, step through absolutely *every* line of code? Every single
error path, no matter how unlikely?

--
Jon Skeet - <skeet@pobox.co m>

http://www.pobox.com/~skeet/

If replying to the group, please do not mail me too

[ncaHammer]

Re: c# 2004 (Whidbey)

"Niall" <asdf@me.com> wrote in message
news:%23Lfp2kIY DHA.2648@TK2MSF TNGP09.phx.gbl. ..[color=blue]
> So my approach isn't perfect, but I doubt anyone's is :P[/color]

Agreed,

read this

http://msdn.microsoft.com/library/en-us/dnbda/html/DBGrm.asp

it might help in some cases

[Bob Jenkins]

Re: c# 2004 (Whidbey)

"Niall" <asdf@me.com> wrote in message news:<OruQj55XD HA.652@tk2msftn gp13.phx.gbl>.. .[color=blue]
> "Alvin Bruney" <vapordan_spam_ me_not@hotmail_ no_spamhotmail. com> wrote in
> message news:%236Tv7bcX DHA.1640@TK2MSF TNGP10.phx.gbl. ..
>[color=green]
> > I think the gist of your argument was you would rather unit test than
> > step thru your code. My response was no, that's wrong. you absolutely
> > must step thru every line of code you write. <snip>[/color]
>
> In this case, you need unit testing as you say. If you didn't have unit
> testing, you'd have no idea whether the rest of the system still works after
> you change your code. The thing is... if you're prepared to use unit testing
> for ensuring the safety of the whole of the system when central code is
> changed, why are you not prepared to use it to ensure the safety of the code
> that you're actually changing. Ideally, if there's a bug, you should write a
> test which fails because of the bug, and then fix it.[/color]

Just add to the unit test, or add to the unit test and walk through
the new code as the relevant part of the test is run as well?

I recall once when I just added to the unit test. It showed what I'd
done gave the correct result. Another developer insisted on walking
through the code as the test was run, which I thought was pointless,
since it produced the correct result. But walking through the code
revealed that there was a graph walk that was taking exponential time
because of bugs in my conditions for which nodes to recurse on.

Some programs have a lot going on that doesn't show up in the results,
but is visible when you step through the code.

[Alvin Bruney]

Re: c# 2004 (Whidbey)

good point
"Bob Jenkins" <bob_jenkins@bu rtleburtle.net> wrote in message
news:a5d787df.0 308131020.626bf c9d@posting.goo gle.com...[color=blue]
> "Niall" <asdf@me.com> wrote in message[/color]
news:<OruQj55XD HA.652@tk2msftn gp13.phx.gbl>.. .[color=blue][color=green]
> > "Alvin Bruney" <vapordan_spam_ me_not@hotmail_ no_spamhotmail. com> wrote[/color][/color]
in[color=blue][color=green]
> > message news:%236Tv7bcX DHA.1640@TK2MSF TNGP10.phx.gbl. ..
> >[color=darkred]
> > > I think the gist of your argument was you would rather unit test than
> > > step thru your code. My response was no, that's wrong. you absolutely
> > > must step thru every line of code you write. <snip>[/color]
> >
> > In this case, you need unit testing as you say. If you didn't have unit
> > testing, you'd have no idea whether the rest of the system still works[/color][/color]
after[color=blue][color=green]
> > you change your code. The thing is... if you're prepared to use unit[/color][/color]
testing[color=blue][color=green]
> > for ensuring the safety of the whole of the system when central code is
> > changed, why are you not prepared to use it to ensure the safety of the[/color][/color]
code[color=blue][color=green]
> > that you're actually changing. Ideally, if there's a bug, you should[/color][/color]
write a[color=blue][color=green]
> > test which fails because of the bug, and then fix it.[/color]
>
> Just add to the unit test, or add to the unit test and walk through
> the new code as the relevant part of the test is run as well?
>
> I recall once when I just added to the unit test. It showed what I'd
> done gave the correct result. Another developer insisted on walking
> through the code as the test was run, which I thought was pointless,
> since it produced the correct result. But walking through the code
> revealed that there was a graph walk that was taking exponential time
> because of bugs in my conditions for which nodes to recurse on.
>
> Some programs have a lot going on that doesn't show up in the results,
> but is visible when you step through the code.[/color]

[Niall]

Re: c# 2004 (Whidbey)

Add to the unit test and run it to check that the result shows that the bug
has been located. In the case that I'm fixing a bug, I take the situation
that causes the bug and put it in a test, then run the test to make sure
that it fails, and hence is correctly trapping the bug. Then I step through
the function and work out why it's not working as intended. At this time,
you may become aware of more conditions in which this bug shows itself, and
hence you add to your unit test. Then you make your fix, and run the unit
test. If you're especially paranoid, you can step through the code again at
this point. But if you have written your unit test properly, there is no
gain to be made by stepping through the code. In fact, if you can pick up
bugs in stepping through your code that your test cannot pick up, then you
have not written a complete test.

If it's performance you're concerned about, do you walk all your code just
to see how it performs? You could walk through each line in a function, make
sure it's not looping one too many times or some such thing. But you will
have no idea whether your function is being called too many times by other
parts of the system unless you do a full code walkthrough.

When I code, I keep a general mind towards the performance of my code. But I
don't spend too much time trying to make sure it runs as fast as possible,
because it can lead to less clear code, and I can be wasting time making
code that runs in a negligable time run in even less negligable time. If I
notice something that is too slow, I will profile it. Every now and then, I
do general profiles on the system (both performance and memory usage) to see
what kind of a state we're in. If anything stands out, I have a look at it,
profile more specifically, and go from there.

I know this goes against the older style of coding of not "Can you get blood
from a stone?" but "How much more blood can you get from this stone if you
squeeze a little harder?", and no doubt a lot of people disagree with this
mindset, but... If the code you have written fully and correctly meets
business purposes (and you can prove this through passing unit tests), and
there is no noticeable lack of performance, why do you need to step through
your code? Stepping through code for performance checking can be insightful,
but if you don't know that it actually causes a performance problem for the
end user, it is often random, aimless and virtually fruitless.

Niall

"Bob Jenkins" <bob_jenkins@bu rtleburtle.net> wrote in message
news:a5d787df.0 308131020.626bf c9d@posting.goo gle.com...[color=blue]
> "Niall" <asdf@me.com> wrote in message[/color]
news:<OruQj55XD HA.652@tk2msftn gp13.phx.gbl>.. .[color=blue][color=green]
> > "Alvin Bruney" <vapordan_spam_ me_not@hotmail_ no_spamhotmail. com> wrote[/color][/color]
in[color=blue][color=green]
> > message news:%236Tv7bcX DHA.1640@TK2MSF TNGP10.phx.gbl. ..
> >[color=darkred]
> > > I think the gist of your argument was you would rather unit test than
> > > step thru your code. My response was no, that's wrong. you absolutely
> > > must step thru every line of code you write. <snip>[/color]
> >
> > In this case, you need unit testing as you say. If you didn't have unit
> > testing, you'd have no idea whether the rest of the system still works[/color][/color]
after[color=blue][color=green]
> > you change your code. The thing is... if you're prepared to use unit[/color][/color]
testing[color=blue][color=green]
> > for ensuring the safety of the whole of the system when central code is
> > changed, why are you not prepared to use it to ensure the safety of the[/color][/color]
code[color=blue][color=green]
> > that you're actually changing. Ideally, if there's a bug, you should[/color][/color]
write a[color=blue][color=green]
> > test which fails because of the bug, and then fix it.[/color]
>
> Just add to the unit test, or add to the unit test and walk through
> the new code as the relevant part of the test is run as well?
>
> I recall once when I just added to the unit test. It showed what I'd
> done gave the correct result. Another developer insisted on walking
> through the code as the test was run, which I thought was pointless,
> since it produced the correct result. But walking through the code
> revealed that there was a graph walk that was taking exponential time
> because of bugs in my conditions for which nodes to recurse on.
>
> Some programs have a lot going on that doesn't show up in the results,
> but is visible when you step through the code.[/color]

[Bob Jenkins]

Re: c# 2004 (Whidbey)

"Niall" <asdf@me.com> wrote in message news:<u6NDsggYD HA.2032@TK2MSFT NGP10.phx.gbl>. ..
[color=blue]
> I know this goes against the older style of coding of not "Can you get blood
> from a stone?" but "How much more blood can you get from this stone if you
> squeeze a little harder?", and no doubt a lot of people disagree with this
> mindset, but... If the code you have written fully and correctly meets
> business purposes (and you can prove this through passing unit tests), and
> there is no noticeable lack of performance, why do you need to step through
> your code? Stepping through code for performance checking can be insightful,
> but if you don't know that it actually causes a performance problem for the
> end user, it is often random, aimless and virtually fruitless.[/color]

Good point -- any testing method has to be monitored to see how useful
it is in the current situation.

In the situation I deal with (debugging other people's code in a large
old product), walking through the code finds bugs quite easily, easier
than I can find them by probing with testcases or just reading the
code. For me, walking through code is sort of a directed code review.
It catches things not so much because the code is going down the
wrong path, but because it focuses my attention on the active pieces
of the code and lets me verify variables are actually set. Expensive
things in inner loops, uninitialized variables, conditions that don't
make sense but happen to come out right for the current case,
realizing the current routine shouldn't be hit at all, noticing flags
aren't set the way I thought they were -- all that I catch by walking
through the code.

80% of the time I walk through my code after it's fixed my testcase,
and about 95% of the time I find something I did wrong, or was wrong
before my changes. I get nervous when I find everything went right
the first try.

[Niall]

Re: c# 2004 (Whidbey)

I know what you mean. I'm not saying that the debugger is useless or a sin,
I just don't agree that it should be entrenched as "required practice" in
development, which is not what you're saying anyway (I think). Stepping
through the code can be helpful to see if you've designed your code badly,
but I don't think it's a requirement. If unit tests show that the program
does what it's supposed to, and its performance is acceptable, then you can
release it to the client without ever needing to step through the code.

But I agree that you can use the debugger to catch situations where code
could be improved. I don't have an attitude that "as long as it's working
and fast, then the code can be as bad/messy/whatever as you want", but at
the end of the day, such code/design tuning doesn't really bother the
client.

Incidentally, one thing I like to do every now and then to check up on
performance, is to run a profiler on the SQL Server to see all the queries
come in. You can quickly get a good idea for how much SQL you'll be
generating just by opening up some forms/doing some things. If you see the
same select query repeated in quick succession, you know you could probably
improve that. If I see that such a repeated query has a high duration, then
I go have a look.

Niall

"Bob Jenkins" <bob_jenkins@bu rtleburtle.net> wrote in message
news:a5d787df.0 308140939.19a48 e54@posting.goo gle.com...[color=blue]
> "Niall" <asdf@me.com> wrote in message[/color]
news:<u6NDsggYD HA.2032@TK2MSFT NGP10.phx.gbl>. ..[color=blue]
>[color=green]
> > I know this goes against the older style of coding of not "Can you get[/color][/color]
blood[color=blue][color=green]
> > from a stone?" but "How much more blood can you get from this stone if[/color][/color]
you[color=blue][color=green]
> > squeeze a little harder?", and no doubt a lot of people disagree with[/color][/color]
this[color=blue][color=green]
> > mindset, but... If the code you have written fully and correctly meets
> > business purposes (and you can prove this through passing unit tests),[/color][/color]
and[color=blue][color=green]
> > there is no noticeable lack of performance, why do you need to step[/color][/color]
through[color=blue][color=green]
> > your code? Stepping through code for performance checking can be[/color][/color]
insightful,[color=blue][color=green]
> > but if you don't know that it actually causes a performance problem for[/color][/color]
the[color=blue][color=green]
> > end user, it is often random, aimless and virtually fruitless.[/color]
>
> Good point -- any testing method has to be monitored to see how useful
> it is in the current situation.
>
> In the situation I deal with (debugging other people's code in a large
> old product), walking through the code finds bugs quite easily, easier
> than I can find them by probing with testcases or just reading the
> code. For me, walking through code is sort of a directed code review.
> It catches things not so much because the code is going down the
> wrong path, but because it focuses my attention on the active pieces
> of the code and lets me verify variables are actually set. Expensive
> things in inner loops, uninitialized variables, conditions that don't
> make sense but happen to come out right for the current case,
> realizing the current routine shouldn't be hit at all, noticing flags
> aren't set the way I thought they were -- all that I catch by walking
> through the code.
>
> 80% of the time I walk through my code after it's fixed my testcase,
> and about 95% of the time I find something I did wrong, or was wrong
> before my changes. I get nervous when I find everything went right
> the first try.[/color]

[Mark Pearce]

Re: c# 2004 (Whidbey)

Hi Niall,
[color=blue][color=green]
>> If unit tests show that the program does what it's supposed to, and its[/color][/color]
performance is acceptable, then you can release it to the client without
ever needing to step through the code. <<

There are so many things wrong with this attitude that I don't know where to
start debugging your thought processes!

Unit tests can only test your current thinking about what your code should
be doing. Most developers can virtually guarantee that the first ideas about
what their code should be doing is faulty. One of the major tools for
correcting your ideas is to walk through your code in a debugger to watch
the code flow and data flow. Relying on unit tests is just intellectual
laziness, a prop for faulty thinking.

In addition, code coverage tools used to verify your unit tests are not very
useful. They can't identify what the code should be doing, or what it isn't
doing. But developers tend to use these tools to say "But there can't be a
bug: my unit tests are infallible and my code coverage tool verified that
all paths have been executed".

In my company, developers are required to walk through all of their code. If
I find a developer has missed a bug that would have been caught by walking
through the code, that developer is in trouble. If the same developer
continues to miss bugs through not walking through code, she/he is out of
the door. So far, this has only happened once - worked wonderfully for
"encourager les autres" :)

Regards,

Mark
--
Author of "Comprehens ive VB .NET Debugging"

http://www.apress.com/book/bookDisplay.html?bID=128

"Niall" <asdf@me.com> wrote in message
news:OtPdHetYDH A.4020@tk2msftn gp13.phx.gbl...
I know what you mean. I'm not saying that the debugger is useless or a sin,
I just don't agree that it should be entrenched as "required practice" in
development, which is not what you're saying anyway (I think). Stepping
through the code can be helpful to see if you've designed your code badly,
but I don't think it's a requirement. If unit tests show that the program
does what it's supposed to, and its performance is acceptable, then you can
release it to the client without ever needing to step through the code.

But I agree that you can use the debugger to catch situations where code
could be improved. I don't have an attitude that "as long as it's working
and fast, then the code can be as bad/messy/whatever as you want", but at
the end of the day, such code/design tuning doesn't really bother the
client.

Incidentally, one thing I like to do every now and then to check up on
performance, is to run a profiler on the SQL Server to see all the queries
come in. You can quickly get a good idea for how much SQL you'll be
generating just by opening up some forms/doing some things. If you see the
same select query repeated in quick succession, you know you could probably
improve that. If I see that such a repeated query has a high duration, then
I go have a look.

Niall

"Bob Jenkins" <bob_jenkins@bu rtleburtle.net> wrote in message
news:a5d787df.0 308140939.19a48 e54@posting.goo gle.com...[color=blue]
> "Niall" <asdf@me.com> wrote in message[/color]
news:<u6NDsggYD HA.2032@TK2MSFT NGP10.phx.gbl>. ..[color=blue]
>[color=green]
> > I know this goes against the older style of coding of not "Can you get[/color][/color]
blood[color=blue][color=green]
> > from a stone?" but "How much more blood can you get from this stone if[/color][/color]
you[color=blue][color=green]
> > squeeze a little harder?", and no doubt a lot of people disagree with[/color][/color]
this[color=blue][color=green]
> > mindset, but... If the code you have written fully and correctly meets
> > business purposes (and you can prove this through passing unit tests),[/color][/color]
and[color=blue][color=green]
> > there is no noticeable lack of performance, why do you need to step[/color][/color]
through[color=blue][color=green]
> > your code? Stepping through code for performance checking can be[/color][/color]
insightful,[color=blue][color=green]
> > but if you don't know that it actually causes a performance problem for[/color][/color]
the[color=blue][color=green]
> > end user, it is often random, aimless and virtually fruitless.[/color]
>
> Good point -- any testing method has to be monitored to see how useful
> it is in the current situation.
>
> In the situation I deal with (debugging other people's code in a large
> old product), walking through the code finds bugs quite easily, easier
> than I can find them by probing with testcases or just reading the
> code. For me, walking through code is sort of a directed code review.
> It catches things not so much because the code is going down the
> wrong path, but because it focuses my attention on the active pieces
> of the code and lets me verify variables are actually set. Expensive
> things in inner loops, uninitialized variables, conditions that don't
> make sense but happen to come out right for the current case,
> realizing the current routine shouldn't be hit at all, noticing flags
> aren't set the way I thought they were -- all that I catch by walking
> through the code.
>
> 80% of the time I walk through my code after it's fixed my testcase,
> and about 95% of the time I find something I did wrong, or was wrong
> before my changes. I get nervous when I find everything went right
> the first try.[/color]