[fpc-pascal] Comparing version numbers

[L505]

> On 6/3/06, Jilani Khaldi <jilani.khaldi1 at virgilio.it> wrote:
> > > Learn to code with UnitTests (process is called Test Driven
> > > Development).
> >
> > Never used. How does this work? I found only a unit called
> > "UnitTests.pp" and nothing else.
>
> Use an xUnit testing framework while coding.  Free Pascal comes with
> fpcUnit.  Under Delphi people normally use DUnit.  Under Java they use
> JUnit, etc...
>
> Regarding TDD (Test Driven Development) look at the following websites:
> In short - You write a test, Write the code, Run the tests, Refactor.
> Then repeat the whole process...  The first 3 steps should be
> completed in under a minute.  As I said, it is very different to
> traditional programming style, but once mastered, you can't think of
> programming any other way.

I've said this before but most of the test-driven development stuff is kind of quack. That
a program needs to be tested, is common sense.  The programs which need to be
tested more, are programs that are going to be used frequently.  Write programs that
test your library or program, but don't buy books or read web pages about that quack
called test-driven development - because it's just books about common sense - flawed
common sense, actually.

You simply can't always write tests *before* you develop your program because this is
too much design up front. If you know all the tests you should write before you even *have
your program coded*, then you are designing too much up front, and knowing too much
up front - this is not the way case in programming - the program changes as you start
developing it. So you can't test for everything before you write any code.

Sometimes you need a quick program that will only be used a few times in the entire year,
and writing tests would be a waste of time.

And as for the testing suite that FPC uses - this is not even "test driven development",
according to the true definition of test driven development. The test suite that fpc has
are composed of a bunch of tests written by users and developers who found bugs after the
code for FPC was already written. In other words, most of us realistically write code
before writing tests - and the most effecient way to write tests is have your users write
the tests, if you can. A bug reporting system is a testing system. But since bugs come
after code has written, this must be against the test driven development model. I bet the
test driven development model requires that you write all your bugs before any code is
written - so that you don't need a bug reporting system. Hogwash.

Use common sense - test the hell out of your programs if they are going to be used 100
times per day, if you are having lots of problems with that program. If you aren't having
any problems with that program - and it's doing its job - testing the program would be
like beating a dead horse. All programs have bugs - but if the bugs affect no one, then
there is no point in fixing those bugs. FPC for example has about a million undiscovered
bugs - and no one in their right mind could know those bugs ahead of time by writing tests
ahead of time - it's not humanly possible. Realistically, and reasonably (which
test-driven development is not) most of the bugs are going to be tested for after some
code is written for the job first.  If you write tests first, you might be writing stupid
tests that you already know work - because what you know works, is the tests you will
write for! What you don't know works, isn't written yet - so you can't test it yet. Those
are the tests that you need to spend time on - the stuff you don't know - not the stuff
you know. Until you write complicated code that's broken, you can't write a good test. But
this isn't what TDD pages or books seem to claim.

Write your own tests by hand - don't use any "testing framework". It's simply easier to
write mini programs that test your code, than it is to use some testing framework. Each
program and each library you write will need to be tested uniquely - a framework is
impossible since there is no "framework" around testing. Testing is unique - anything so
unique as testing cannot possibly have a framework. A web program will need completely
different tests, and completely different prioritization of what to test than a search
utility program or a file back up program, or a you-name-it program.

What people do need to learn about tests - is that they need to save their tests. Save
them for later. This doesn't mean you need a testing framework. It simply means you need
to dedicate a /tests/ folder in your project directory and save some tests there. But
imagine you spend several days writing tests for a large project ahead of time - before
writing actual code for the project - then you finally get around to writing the project
and you find out that the project is a no-go. People don't want the project. Your software
idea was good for a few folks - but the product isn't needed on the market - there was
only 1-5 people who needed it per city. So you wasted all that time writing tests when you
could have wrote a quick demo program and see if people needed it at all.

In summary, "test-driven development" is not going to magically solve any problems like
they say it will in the books and on those web pages. Writing tests using common sense
will help you - but reading into the magical test-driven quack out  there will just slow
you down. Learning that you must SAVE and write your tests down is smart - but following
word for word some quackery like TDD is  going to make things worse for you.

Just my opinion. Beware of the TDD consultants.

--
L505