jolz wrote:
>And don't thread.
So how do I write gui application?
Briefly, sometimes you need threads. Fight them, because they are bad. They
are like 'goto'. Don't thread just because "my function runs too long, and I
want to do something else at the same time". Fix the function so you can
time-slice its algorithm. That overwhelmingly improves your design, anyway.
The tutorials for threads often give lame examples that only need simpler
fixes. The tutorials often don't examine the full rationale for threading.
If you drive with one hand and eat a sandwich with another, you might need a
thread. Internet Explorer probably uses threads. If our apps are simpler, we
shouldn't need them, and should resist adding them until we explore all
possible alternatives.
Do you really write for example
database communicatin from gui thread?
The question here is simple: Why and how does communication block your GUIs
thread?
Winsock, for example, fixed that (for 16-bit Windows without much thread
support) by turning network input into a window message. If you have input
communication, you can often _research_ to find the right function that
multiplexes its events together with your GUI events.
If you can't find such a function, then you must use a thread, and you
should use PostMessage() or similar to send events to your GUI thread. If
you thread, make sure your code in both threads is sufficiently event-driven
that you don't need to abuse your semaphores.
Threading violates encapsulation when one thread must remain "aware" of
another thread's intimate details, just to get something done.
If so, how do you allow user to
stop the operation.
I didn't say "lock the GUI up early and often". I just said "don't thread".
There's a lot of middle ground.
So how do you guess what
is the correct time?
or you set the time comfortably close to what
the code currently does.
What is the purpose of test if I write test so it allways passes?
A test here and there that can't fail is mostly harmless. Note that, under
TDD, you often write tests and show them failing at least once, before
passing them.
The purpose of my time example is to instantly fail if someone "upgrades"
the tested code and exceeds the time limit. They ought to see the failure,
Undo their change, and try again. Even if the test defends nothing, the
upgrades shouldn't be sloppy.
And what about changing hardware? Rewrite all tests?
Nobody said time-test all tests.
Change 1 global
settings and pray that it is changed with correct proportion? Or maybe
make new settings so all test passes?
To continue your digression here, one might ask what we expect to do without
tests when we change 1 global variable (besides not use global variables).
Should we debug every function in our program? Of course not, we just run
out of time. So we debug a few of them, and _then_ we pray.
That is the most common form of implementation, and it is seriously broken.
>But it must pass on every developer machine, too.
Does really tests that run few hours/days are run on all machines in a
company?
Yes, because developers are running all the tests before integrating their
code. If any test fails, they don't submit. So the same tests must pass on
every machine, many times a day.
What do you do before integrating? Spot check a few program features,
manually?
>GUIs are always unit testable. They are just a bad place to start
learning!
I'v seen tester trying to write a gui test.
That is QA, and test-last. That means it's a professional tester, trying to
write a test that will control quality. And she or he is using the program
from the outside, not changing its source to write the test.
That's all downhill from the kind of testing we describe here. And without a
unit test layer, it's bloody impossible. But they keep trying!
Heard about others. It was
allways a lot of work with minor advantages. It was only testing
behaviour. Never how application looks. And it was an easier version -
java gui. I hava no idea how can't be it even worse in language without
gui in a standart.
And that is probably describing Capture/Playback testing, which is the worst
of the lot.
Now if I can write a test, in the same language as the tested code, that
tests how our program drives the database, or the file system, why can't I
write a test that checks how we drive the GUI? What's so special about GUIs?
>Short-term, tests make development faster by avoiding debugging,
including
all the "program in the debugger" that everyone does with modern editors.
Debugger also won't work in any of situations I presented. The fact
that test isn't worse than debugger doesn't mean that it usefull.
That is a different topic. I mean that TDD prevents the need to run the
debugger. Programming teams who switch to TDD routinely report that they
never even turn their debugger on; never set a breakpoint; never inspect a
variable.
I didn't quite get how uml causes bugs. But let's not start another
off-topic from this one.
UML doesn't cause bugs. Drawing a UML diagram, then converting the diagram
to code full of empty classes with no behavior, causes bugs. All the classes
are empty, but they inherit and delegate properly! Then you must debug, over
and over again, to put the behavior in.
>Each and every time
you get a Green Bar, you could integrate and ship your code.
Again the thing that scares me the most. Green = good. Don't think
about anythink else. If it's green so it must work. Well, it doesn't.I
have nothing against tests. Sometimes they are usefull. But they don't
solve all developer's problems.
Nobody said that, so don't extrapolate from it.
Under TDD, sometimes you predict the next Bar will be Red. The point of the
exercise is you constantly predict the next Bar color, and you are almost
always right. Predictability = good. It shows that your understanding of the
code matches what the code actually does.
--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
