[fpc-pascal] Comparing version numbers

[Graeme Geldenhuys]

On 6/3/06, L505 <fpc505 at z505.com> wrote:
> 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

A am afraid you are very misguided about what Test Driven Development
actually is!!!  Do yourself (and everybody on this list) a favour and
by the book mentioned below (it's cheap, only $30) and try the
examples.  This way you will actually know what TDD is.

Test Driven Development: By Example (written by Kent Beck)
http://tinyurl.com/kjl8a

A few points to correct some of you statements.

* TDD is a different way of thinking compared to traditional
programming. It takes some getting used to, but once you grasp the
concept it is brilliant.
* You do *not* write *all* tests before you start coding! You write a
single test, testing a small part of your problem representing a small
step of progress. This test should represent how you would like to use
your code (the ideal interface, though it might change later) That
test should fail because it hasn't been implemented yet. You then do a
minor change (should take under a few seconds) in code (sometimes even
hard code the result) to get the test to pass. You then refactor your
code to get rid or all duplication (could be code duplication or data
duplication). Your test should still pass.  Now you move on to the
next small test and repeat the whole cycle.
* Saying only frequently used applications should be test is
ludicrous!  So running a mission critical app once at the end of the
year processing all data from the whole year shouldn't be tested?  All
code that has no obvious solution should be tested!  It's like
building a car and saying Nah, we don't need to test the airbags
because they wouldn't be used in your everyday commute!!
* TDD doesn't actually slow down you coding at all. The first three
steps should all happen under a minute. That's writing the test and
making the test pass in the quickest possible way.  Refactoring the
code to remove duplication takes longer. Once completed, you know know
that part of code works and has a test to prove it. You can now base
other code on that with the confidence knowing it works.


> your program coded*, then you are designing too much up front, and knowing too much

Exactly the opposite.  No design is done up front (the major
difference to traditional programming).  You are only testing a tiny
part of a problem that represents progress, not the complete solution.
 You use the ideal interface that you would like to use in the end on
you library or whatever (though it might change because nobody can
foresee a perfect solution upfront).

> 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

This is why I know you are confused between using a xUnit Testing
Framework and TDD.  FPC doesn't use fpcUnit, they use their own home
grown solution. They have tests to confirm things they have fixed.  So
now they can continue implementing new things, and if anything new
breaks old code, their tests will notify them of that! The same bug
cannot be reintroduced again, ever!


> code for FPC was already written. In other words, most of us realistically write code
> before writing tests -

I did say TDD is different to the normal way of coding.


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


Oh, so you would rather release you buggy product to the world and let
them find problems you didn't think of.  Boy, will you look like a
real good developer when those bug reports start streaming in.  Not to
mention, how many sales you will loose after potential clients hear
about you buggy software, and that they need to waste their time,
telling you about things you should have done right the first time.
I would rather release code, I know that works, and have the
confidence in my product because I know my unit tests pass.  Yes there
might still be some test I didn't think of, but at least I should have
a much more reliable product than yours.
The process of handling those minor bug reports are explained next.



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.

If a bug gets reported, I would add to my test suite a new test that
exposes that bug (the test will fail), then fix the bug and the test
should pass.  Now that bug cannot be reintroduced without me knowing
about it (this is kinda what the FPC Team is doing as far as I can
see).


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


Now I have heard it all!!!  If you know about a bug, it should be fixed.


> 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

Wrong again.  You write a test to represent a small step of progress
towards the ultimate solution.  That test should fail, until you have
implemented it and refactored to get rid of duplication.  You should
really read that book written by Kent Beck, you have no clue what TDD
actually is!

> 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

Now you are proving that you don't know what a Testing Framework is.
A testing framework gives you the tools to write test really fast and
in a uniform manner.  It also guarantees that results for those test
will be presented after the test run has completed.  All tests will be
in a uniform style and shows you how you are supposed to use a
function or library, etc.. (almost like a programmers manual if you
like).

All I can say, is that you are completely misguided in what you think
Test Driven Development is, or even a xUnit Testing Framework for that
matter. Spend the $30 wisely and buy the book mentioned (no I don't
get any commision on sales. Kent Beck doesn't even know I exist).


Regards,
  Graeme.