Re: edit & continue

From: Daniel O'Connell [C# MVP] (onyxkirx_at_--NOSPAM--comcast.net)
Date: 03/15/04 

Date: Mon, 15 Mar 2004 03:34:26 -0600

"Michael Culley" <mculley@NOSPAMoptushome.com.au> wrote in message
news:OWLVNajCEHA.2616@TK2MSFTNGP12.phx.gbl...
> "Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
> message news:uJUce8ACEHA.1236@TK2MSFTNGP11.phx.gbl...
>> I must ask, why are you testing that way? Shouldn't you be testing all
>> your
>> individual chunks of code in a more modular way instead of running from
>> point A all the way to point X? Outside of errors in the UI(which are
>> hard
>> to test outside of debugging), I don't think the approach you use here is
>> as
>> good an idea as you seem to.
>
> Every time I get into this sort of thread the programmers all of a sudden
> become perfect. They plan their projects down to the last
> details and unit test everything, they write and check all of their code
> before they run it and most of the time it runs ok first
> time. They have a team of testers and bugs rarely appear on the end users
> machine. Maybe if you are writing a new file system then
> this would be reality but when you are writing an app with 300 forms on
> your own in limited time it's a bit different. Anyway,
> that's a different story, the fact is I don't generally do unit testing
> and just run the app in the dubugger to test it. The
> majority of other programmers would be the same.
>

I'm really astounded you'd consider what I'm implying perfection, I consider
it pretty off the cuff and risky personally. The approach you suggest, with
testing in the debugger has lead me to create what had to be among the worst
apps in existance. In my first year professionally, I wrote an app for a
construction company, charged with organizing some of their internal
business. It was in vb6 and I make two mistakes, 1) I abused ADO, and 2) I
abused E&C. The abuse of ADO is very apparent, and pretty irrelevent, as it
only made the app slow. The abuse of E&C instead made the code hard to fix
when I did figure out where the abuses of ADO existed. As I analyze that
code(and, a great many other chunks here and there as well by other
authors), you can see places where methods were modified in some *stupid*
way because it fixed the immediate problem, sometimes to the point that
fixing the original problem caused the method to fail because the immediate
fix screwed up the remote fix. That is the problem with E&C, and the legacy
from abuse is something anyone who ever works on material other than their
own. It is *far* too easy, and horridly common, to write code for E&C. And
yes, I am worried about it.

There are other situations where unit testing isn't going to happen. Right
now I am playing with a compiler in my spare time(the Mono C# one), and
there is little realistic way to perform unit tests, especially given vs's
refusal to load exe's as references. So instead I have test scripts that run
across my own function tests, and occasionally I run the supplied regression
tests(although, thats my one beef with mono, the damn compiler they ship as
source never seems to work the same as the binary one, so tests tend to fail
and cause headaches). The downside is although the scripts ensure that there
are no regressions and that the code compiles as it should, I am still stuck
using ildasm myself and verifying that the code outputted is what I expected
and in general correct.
>> Anyway, tell me, what arguments do you have for it? Just the "I hate
>> having
>> to restart when I screw up" argument(which, incidentally, is the only
>> argument I've ever heard in favor of E&C;
>
> What other reason do you want? That's what it does, that's ALL it does.
>
> Your reasons are much more vague than this. Really, stop and read your
> post and then read the above three lines you wrote. This is a
> solid reason, "If I encounter a simple mistake I can fix it without
> restarting and save time" as compared to all sorts of coding
> practice talk that only seems to apply if you are following a certain
> coding practice.

I follow only the practices I've found usefull. Unit testing(be it formal,
using NUnit or the like, or informal, using console utilities that you'll
never understand again and really aren't very useful for anyone but you)
isn't really that hard. Now, granted, in the above situation you described,
of 300 forms that is, I suspect E&C and the debugger is your best choice.
Unit tests of any kind for UI code is possibly the most difficult type of
test to do, and I don't really believe that they'll ever actually be right
anyway. There are too many variables and what data is returned doesn't
matter, its what users see and how it behaves in real use. That is why, alot
of the time, the first bug you run into in any given app is a UI bug. Its
rather difficult for even a professional test team to really work out a UI.
I hear that whidbey or longhorn(I think longhorn) is supposed to deliever a
more robust framework for accessiblity that will also allow testing UI code,
but that is a ways off yet.

Anyway, perhaps alot of my reasons for not seeing a use in E&C is that I
write very little UI code, when I do the UI tends to be little more than a
form and event handlers that calls into the classes I tested earlier on. I
can't even do databinding on my own, ;).

I also can't say that I spec everything properly, infact I argue against TDD
for that reason. When I was playing with it, I found that most of the time
the tests I wrote to follow the spec were a waste of time because when I sit
down to write the system I realize that the system can't communicate with
itself, or other such annoyances, but the tests said the system was right. I
find myself writing alot of little console apps just to demonstrate the use
of an infrastructure, both internally and externally, but I can't say thats
good practice, just that its what it takes to get what I'm doing right.

Frankly, I'd love to have even one tester so I didn't have to spend so much
time dreaming up ways to hammer my classes with stuff that should never be
passed to the method in the first place and actually get some more work
done.

>
>> Does that really justify E&C?
>
> Yes.
>
>> Is
>> it enough, given the enormous potential for abuse, to make E&C a "good"
>> feature? Enlighten me, be the first to provide an actual reason.
>
> The abuse of it is not your problem. I don't think the inclusion of it
> will promote bad coding practices, programmers will continue
> with the same practices regardless.
>
>> Furthermore, E&C doesnt fix the situation, which isn't uncommon, where
>> the
>> code that causes the error actually occurs in the first few lines of the
>> program, even if the manifestation of that error doesn't occur for 6000
>> lines.
>
> In that situation EnC is not of much use but I find it is more common that
> the error is in the current procedure or a little further
> up the call stack and can be fixed fairly easily.

Everyone sometimes makes silly mistakes, assigning the wrong enum value or
mis-casing a case sensitive string argument. Or my fav, and probably the one
I do most often, forgetting to reassign a string to itself after an
operation(string.SubString() on its own doesn't do a whole lot). However, I
really don't find those mistakes(ones that compile anyway) to be that
common. Most mistakes I find are due to logic errors or to writing something
that plain doesn't compile. My code certainly isn't perfect but it is
generally as right as possible for how wrong it is.

>
> --
> Michael Culley
>
>

Relevant Pages

  • Re: TypeInitializationException / forcing all static ctors to run on startup
    ... But, if my app wasn't, and the unit tests were in another ... I can totally see why this test project would be run much ... It's the *reason* my app is run so often - for testing. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Opinion wanted
    ... the details including the nature of my own app (which you mischaraterized ... correct the current control (provided that control is invalid but invalid ... causes you to validate controls that have already been ... largely discreditted for good reason and has very little use these days. ...
    (microsoft.public.dotnet.framework.windowsforms)
  • Re: Tablets? - OT
    ... - the main reason for porting was so idiots could maintain the code ... on a yellow legal pad. ... to find anyone to pay me to play with it. ... and an app that calculated the temperature from cricket chirps. ...
    (microsoft.public.vb.general.discussion)
  • Re: [PATCH/RFC] A method for clearing out page cache
    ... > app designers very frequently think that the VM gets its act wrong (most ... Any left over cache is wrong, ... coupled jobs. ... reason, perhaps this is such a reason. ...
    (Linux-Kernel)
  • Re: Why choose Kerio instead of ZA?
    ... Why would KPF2 have those open? ... > i/o is buffered, so it doesn't matter much anyway. ... but there must be some reason for it. ... It enables you to restart the app without rebooting on most ...
    (comp.security.firewalls)