> On 6/3/06, Jilani Khaldi <[EMAIL PROTECTED]> 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 _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
