PureBasic Forums - English

I've started using TDD with jUnit with Java, and I rather like it.

I'd like to take a similar approach with PureBasic, anybody already doing this. What approach do you take?

Would their be much demand for PureUnit?

Test Driven Development? Is this another american style buzzword regarding a new style of management? Just a guess! I tend to hear BS terms like this all the time during work hours.

Any links to direct us to for more information?

Test Driven Development is not a management process but a programming technique. It's one of the elements taken from Extreme Programming.

I've been giving it a try with Java and it is good.

http://en.wikipedia.org/wiki/Test_driven_development

The process goes like this:

You want to write some code. The first thing you do is write a test for the code you are going to write. Run the test to make sure it fails.

Now write your code. Run the test to make sure it passes.

Now you write you're next bit test for the next bit of code. Keep going.

The great thing about the approach is that writing a test makes you think much more carefully than writing the code straight off. As you continue to work you build up large suite of unit tests.

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

Just kidding.... mostly. I'm a code then test sorta guy, but then again, I don't write mission critical stuff so there you go.

I'm not a mission critical kind of guy either, but I find that the tests never get written afterwards.

What I'm actually finding is great about the TDD approach is that it is good for coding in small bites.

Ever since I've settled down with a home and family I've not had time to code. When I was a younger man I would hack away at my computer until the wee small hours, the same approach as work. Now I just don't have more than a half hour slot to code. It takes longer than that to put together a significant enough piece of functionality to run and work with. If I code for half an hour, then leave it half finished and come back I just can't remember what I was up to. I never get far enough to actually run something.

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. I can sit down, run the tests I have so far and either fix something or add another test.

This reminds to me a story that he says:
Man1.- I masturbate striking my penis with a hammer
Man2.- And where the pleasure is?
Man1.- When I miss the blow

wcardoso,

Its a good joke , but I'm having trouble seeing the link

well..seriously I think it's a bit masochist style of coding, because how supposes your schedule will on time if you need to duplicate the coding work to test, code, test, ever and ever in small chunk.
Better approach is to make small functional routines to post somewhere to being tested by a community or the potential users. This way your code will suffer the "most incredible" hard test you can imagine in real conditions; and with less work from you. This will save your time to use it to continue coding your real program, and not artificial test code who slow down timeline.
Another good effect from this style of coding is the benefits derived of the bug reports and suggestions from your users, some better ideas from they can improve your product (better sales ); and install in your customers the feeling you ear they.

@kale

Test Driven Development? Is this another american style buzzword regarding a new style of management? Just a guess! I tend to hear BS terms like this all the time during work hours.

Spoken like a true Brit You hear them - hey come to one of my presentations and you'll hear a whole lot more. I used to be a good Unix Techy 5yrs ago. I sold my soul and just get paid more money for knowing less but speaking with greater confidence...

aaron wrote: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....

A quote from Wikipedia:

It is also important to note that Test-driven Development only proves correctness of design and functionality according to the testcases written. An incorrect testcase that does not meet the specifications will produce incorrect code. Therefore, the emphasis on correctness and design has shifted to writing testcases since they are the drivers. As a result, Test-driven Development is only as good as the tests are.

8O

Everything about Extreme Programming, from pair programming to test-driven coding is aimed at one goal. THINK BEFORE YOU CODE.

I've worked in an "Extreme Programming" environment before. It helps some developers and hurts others. Some developers already have the discipline and don't benefit much from the Extreme Programming principles and guidelines.

In one very uncomfortable moment during my brief stay at the company where I used Extreme Programming I had an argument with a developer over his test suites. My argument was that I could break the software within 5 minutes by testing the "old fashioned way" - just start the program up and start clicking away. I did, he got very mad, but my point was proven. No amount of simulated tests can compete with a handful of quailty assurannce people (they don't need to be geeks) and a good group of beta testers that actually *use* the software as it is intended. Programmers generally have to be very focus and fall victim to "can't see the forest for the trees" syndrome. Getting another few sets of non-geek eyes on the software is nothing but a good thing.

Getting another few sets of non-geek eyes on the software is nothing but a good thing.

Yes! I absolutely agree! I always pass software i've written over to my friends with instruction for them to try and break it! Sometimes they find very unusual behaviour I probably would never have spotted.

Automatic unit testing complements, rather than replaces, traditional acceptance testing by non technical people.

It's rather like double entry book keeping. Accounting enter every transaction in two places and at the end they make sure the two add up and match each other. If they don't match then they know there is an error somewhere.

At the moment you probably have the functionality for your code expressed in one place, your code. The more disciplined may also have it expressed in documentation. There is a problem, though. When you change the code the documentation is out of sync. Those of you that do have specs, how often do you go though every item in your spec and test it's accuracy? How long would that take.

Unit tests offer a better way of expressing your codes functionality. You capture requirements as unit tests. Then you can run the code against the tests automatically to make sure you haven't inadvertantly broken anything.

If the two disagree, then you know either the code is wrong or the test is wrong. The code ensures the tests are correct, and the tests ensure that the code are correct. When they disagree you have to figure out which one of them is in the wrong.

Karbon, when you fix a bug and make a release, do you test for every other bug that was every reported?

When you're testers report a bug, you replicate it in a unit test first. Then you run it with the rest. Every time you prepare a release you test for every bug that was ever reported.

As the code and tests mature together their coverage increases.

It is all very elegant. I like it.

I'm not personally too enchanted with the notion of writing a priori test cases for every bit of code I design. There is, however, much to be said about the elegance of having a built-in system of testing for every bug ever known to have been fixed, as described above by GedB. Because of this benefit, large projects involving numerous developers may employ test-driven development as a wise and logical choice. There is little more frustrating for the (esp. heavily dependent) end user than seeing a bug fixed in one release, only to see it reappear in some later release.

"Extreme Programming"....lol....

Sorry, just sounds funny to me.