Test Driven Development

[zyzmo]

Hello guys!

Today I had the brilliant idea to begin to learn TDD, but I can't understand how write the tests!

Well, if anyone have time to share a simple "how to", I'll be grateful !!!

Thanks!

PS.: I've read the FPCUnit wiki, but I didn't understand so;

[Graeme]

I recommend you start with FPTest (a FPC specific fork of DUnit2) [http://wiki.freepascal.org/FPTest]. It is much improved and easier to use that FPCUnit, plus it has backward compatibility with DUnit and FPCUnit too.

The concept of writing unit tests are pretty simple.

• You create a new unit which will contain some tests
• Add the TestFramework unit to the Interface section's uses clause
• Define a new test class which descends from TTestCase
• Define test procedures in the Published section of the above mentioned test class
• Implement the test procedures by using the CheckXXX() methods. eg: CheckTrue(), CheckEquals() etc. They normally have two or three parameters... An "expected" value, the "actual" value, and a "error message". My error messages are normally in the format of "Failed on 1", "Failed on 2" etc, so that if I see the error message in the results, I know exactly which test and which CheckXXX() call failed.
• Now you need to register that test class with the testing framework. This is normally done in the Initialization section of the unit. eg: TestFramework.RegisterTest(TMyTest.Suite);
• Test projects can be Console or GUI based, and normally consist of many test units, all defined as above. The project then simply calls RunRegisteredTests, and it will output your test results.

That's it!   

Putting it all together, here is our Console test program unit.

Code: Pascal  [Select][+][-]

1. program project1;
2.  
3.   {$mode objfpc}{$H+}
4. {$IFDEF WINDOWS}
5.   {$APPTYPE CONSOLE}
6. {$ENDIF}
7.  
8. uses
9.   Classes
10.   ,sample_tests // is the unit that contains our tests
11.   ,TextTestRunner   // Enables the Console test runner
12. //  ,GuiTestRunner  // Enables the GUI test runner
13.   ;
14.  
15. begin
16.   RunRegisteredTests;
17. end.
18.  

And here is our unit that contains the tests.

Code: Pascal  [Select][+][-]

1. unit sample_tests;
2.  
3. {$mode objfpc}{$H+}
4.  
5. interface
6.  
7. uses
8.   TestFramework;
9.  
10. type
11.   TTestCaseFirst = class(TTestCase)
12.   published
13.     procedure TestWarning;
14.     procedure TestOne;
15.     procedure TestTwo;
16.     procedure TestThree;
17.   end;
18.  
19. implementation
20.  
21. uses
22.   sysutils;
23.  
24. { TTestCaseFirst }
25.  
26. procedure TTestCaseFirst.TestWarning;
27. begin
28.   // Do nothing here - should cause a Warning
29. end;
30.  
31. procedure TTestCaseFirst.TestOne;
32. begin
33.   Check(1 + 1 = 3, 'Catastrophic arithmetic failure!');
34. end;
35.  
36. procedure TTestCaseFirst.TestTwo;
37. begin
38.   Check(1 + 1 = 2, 'Catastrophic arithmetic failure!');
39. end;
40.  
41. procedure TTestCaseFirst.TestThree;
42. var
43.   s: string;
44. begin
45.   s := 'hello';
46.   CheckEquals('Hello', s, 'Failed CheckEquals');
47. end;
48.  
49.  
50. initialization
51.   TestFramework.RegisterTest(TTestCaseFirst.Suite);
52.  
53. end.
54.  

For further reading I recommend the book Test Driven Development: By Example by Kent Beck.

I hope that helps.  If you have any more questions on FPTest, feel free to join the dedicated support newsgroup.

   NNTP Server:  geldenhuys.co.uk
   Port: 119
   Newsgroup: fptest.support

[zyzmo]

Thank you!

Now I'll study it!

Oh, I have a question, How can I get a button state(Enabled or Not)?


Thank you again!
Seya

[Graeme]

Oh, I have a question, How can I get a button state(Enabled or Not)?

If you are hinting at using Test Driven Development or Unit Testing in general for user interfaces (forms) - that is doable with great effort, but not the intent of unit testing. Unit testing is meant to test non-visual functionality. eg: business rules (eg: salary calculation, tax calculation), expected functionality of a class, result from a function call etc.


As for your button question, query the SomeButton.Enabled value.

[zyzmo]

Thanks for explain Graeme!

In my mind TDD development was to test everything on my code!
I was confused about it, because test all the functionalities sounds insane!

Seya!

[Graeme]

Regarding forms - that is why it is a terrible idea to write code (business logic) inside form units and it's event handlers. It makes it very hard to test such code, and ties you very closely to a specific form and GUI toolkit. Not very portable and testable code at all.

Instead create classes that do the functionality you require, then simply call the methods of that class from the Form unit. That way your "logic" is separated from the User Interface, and it is much easier to test that logic. That logic could then be reused one day, say when you decide to create a Web Based application too.