Anybody using Test Driven Development with Purebasic

[ricardo]

What if you code an error into the test? Do you then write a test for the test?
And then a test for the test for the test....

[utopiomania]

GedB wrote:

With TDD everything is done in much smaller chunks. You code, run, code, run in a much tighter cycle
with the code growing steadily over time.

This is much the way I have been coding for a while. I figure out the overall idea and UI style, then code
the menus, eventhandler loop, buttons etc. but with empty procedures saying 'not implemented' and a
code structure that is easy to change since it's just an empty shell.

The next step is to mess around with the empty framework til I'm satisfied with it, then begin to code
procedures/algorithms and test out each part as I go.

It's probably not 'TDD' though, more like 'top down programming style' or something similar to that.

[Derek]

Sounds like you have to do twice as much work, codeing tests, coding programs to pass the test, back and forth, bugs are going to creep in somewhere, they always do!

[dell_jockey]

GedB,

we've been over this before, sort of.... I like the idea, but it's an awfull lot of trouble to end up with something that DbC (Design by Contract) would provide automatically.

Unfortunately, PB doesn't support DbC...

[Tipperton]

This is what I call extreme programming....

http://www.fastcompany.com/magazine/06/writestuff.html

[GedB]

utopiomania,

That is exactly the approach.

However, do you carry out all your tests manually? If so then you spend so many hours testing one area of the functionality and then move on.

That area of the code is only stable as long as you don't change anything. The code is stuck in stone.

If you had produced some automated tests, then those tests would be repeated over and over again.

If you want to change the code, to improve perforance or increate readability, you can. If you change anything your tests will catch it.

It's a very liberating thing.

[Derek]

This is what I call extreme programming....

http://www.fastcompany.com/magazine/06/writestuff.html

Written in PB and running on a windows XP machine, no doubt.

[GedB]

Ricardo,

The test is validated by the code. The code is validated by the test.

In TDD you always write a failing test first. This shows that your test is working.

Then you write the code, and the test starts to pass. You know that it is the coding that did this, because you haven't changed the test.

Of course, stuff slips past. When a bug is found you start by writing a test to replicate it. Then you fix the bug and the test passes. Now you know that if that bug slips in again, the test will catch it.

It's rather like double entry book keeping. You know that both are right becauge it all tallies up in the end.

[GedB]

Derek,

It's more work up front, but you end up doing a lot less debugging at the end.

With experience, I've found that writing a test for every scrap of code is wasteful. Instead I just write tests for interfaces, using the principles of design by contract.

Wherever two things communicate, there is an interface. That interface has a contract. The tests enforce the contract.

As Dell jockey points out, DbC in Eiffel gives you this for a lot less effort. I think that DbC is the better idea, but I can do TDD right now to implement contracts in any language.

[GedB]

As a follow, my testing tool of choice these days if Fit. I'm working on a PB version.

http://www.rushcoding.co.uk/dw/doku.php#pbfit

Yes, progress is slow. Thats because I have a 1 year old, its not because I'm spending so much time on the tests.

In fact, the java code already has test cases, so I get to reuse them for the port. It makes the task of porting so much easier.

[utopiomania]

GedB wrote:

Code: Select all

However, do you carry out all your tests manually?

Yes, everything is tested manually, and I always try to stick with the simplest most readable
and 'basic' code that I can get away with to get the job done.

Another thing I do, is copy and paste from well tested procedures I keep in a folder, or from
other programs. If I find a problem with copied code, I try and correct all copies of it, this
way the codebase grows more stable over time.

This works well for me and the stuff I write. As I said, I try and keep things simple, and if
it works, it works.

Besides, I too many formal requirements and rigorous testing would probably take all the fun out
of the programming too , so I'll stick with my own simple stuff for now.

[GedB]

utopiomania,

For me the approach has put all the fun back into programming

The main reason is because it puts programming back into the loop that I could enjoy when writing screen based programs, like games.

When writing code that does something on the screen, you write the code, run it and see if it works. You go round and round like that. Write it, test it, write it, test it.

When writing 'professional' stuff the old fashioned way you sometimes don't get to see something running for weeks. Your writing a module that will get called by a framework that will be invoked by a service. You write the code and hope it will work.

Then, weeks later, the job is finally done and somebody is able to get the thing running. Then they find the myriad of little bugs and you run around trying to fix them all.

TDD brings me back to the old way. Write a test, write the code, run the test, write a test, write the code, run the test.

It's so much better.

[AndrewM]

Test driven development could be important to me. I tend to evolve software rather than coding once to a design. Generally, my software needs to be redesigned every few months to cope with new requirements. These redesigns break existing code in parts of the application that I have not worked on. Currently, I have to manually test every control on every form to find issues. I think that unit testing could help with this. Some of the coding teams I work with swear by the technique but I am just researching it at the moment.

Here is a link to the best tutorial/resource on the subject that I have found.

http://www.clarkeching.com/files/tdd_fo ... _final.pdf

What I understand with regard to my style of app development is that unit testing can be used to test all of the user defined functions that I create. Basically, I use the unit testing approach to see if the function can gracefully deal with any type of input.

Another step would be to use unit testing to test interfaces. That I have not figured out yet.

AndrewM

[heartbone]

Any one of the compiler fixes made in the past few days could potentially break something else.
Executing comprehensive testing methodology by using a pre-defined test suite should prove to be useful for compiler developers to employ BEFORE releasing any updates.
A test suite made up from the hundreds of user generated snippets demonstrating bugs could be extracted from this forum,
and they would make a great basis for a quality check tool.

[fsw]

Any one of the compiler fixes made in the past few days could potentially break something else.
Executing comprehensive testing methodology by using a pre-defined test suite should prove to be useful for compiler developers to employ BEFORE releasing any updates.
A test suite made up from the hundreds of user generated snippets demonstrating bugs could be extracted from this forum,
and they would make a great basis for a quality check tool.

I think this is actually what Fred does.
(at least this is what I remember was talked about some years back...)

However, if I'm not mistaken test driven development is actually the same as unit testing.
Both need code that is nicely packaged into self contained procedures that can be tested by themselves.

Both ways are very nice to harden the code.
What the programmer has to let go though is to write the same spaghetti code he used to...