About Test Driven Developments
I-overview ===========
1.What is Test Driven Development (TDD) Test-driven Development (TDD) is the craft of producing automated tests for production code, and using that process to drive design and programming. For every tiny bit of functionality in the production code, you first develop a test that specifies and validates what the code will do. you then produce exactly as much code as will enable that test to pass. Then you refactor (simplify and clarify) both the production code and the test code .-- From www .agileAlliance.org
2.Several Kind of Tests. (1) .unit test. A Tool of developers.small scope, one class usually. (2) .acceptance test. Also called as functional test.perform by Customer. Which One We Should CONCENTRATE ON? Both, They Affect In Different Scene. 3.What is The Benefit A List of Ways Test-First Programming CAN Affect Design: (1) .re-use is good. Test First Code Is Born with Two Clients, Not One. THIS makes adding a third client twice as easy. (2) .Refactoring test-first code results in equally tested code, permitting more aggressive refactorings. cruft is not allowed, and code is generally in better shape to accept more refactorings. (3). When paying attention during all of the little steps, you may discover patterns in your code. (4) .Test code is easy to write. It's usually a couple calls to the server object, then a list of assertions. Writing the easy code first Makes Writing The Hard Code Easy. (5) .DesignPatterns May Be incremented in, NOT ALL OF A BUNC h up front. (6) .Test-first code is written Interface first. You think of the simplest interface that can show function. (7) .Code tends to be less coupled. Effective unit tests only test one thing. To do this You Have to Move The Irrelevant Portions Out of The Way (Eg, MockObjects). This Forces Out What Might Be a Poor Design Choice. (8) .Unittests Stand As Canonical & Tested Documentation for Objects'
usage. Developers read them, and do what they do in production code to the same objects. This keeps projects annealed and on track. (9) .When the developer has to write tests for what he is going to do, he is far less likely to add extraneous capabilities. This really puts a damper on developer driven scope creep. (10) .Test First Design forces you to really think about what you are going to do. It gets you away from "It seemed like a good idea at "programming.4.rhythm of tdd (1) .write a unit test this the system currently doesn't pass. (2) .quickly Write the code to pass Test. (3) .refactor the code to remove any Duplication or other design Nasties (4) .MOVE ON to the Next Unit Test
5.Detailed step (1) .think About what you want to do. (** critical **) (2) .think About how to test it. (** critical **) (3) .write a small test. Think About The Desired API. (4) .write Just Enough Code To Fail The Test. (The Test-Runner, if You're Using Something Like Junit, Shows The "Red Bar "). Now you know what your test is going to be executed. (6) .write Just Enough To Pass The Test (AND Pass All Your Previous Tests). (7) .run and watch all of the tests pass. Test-runner, if you're Using Junit, ETC., Shows The "Green Bar"). If IT DOESN '' Pass, You Did Something Wrong, Fix It Now Since It's Got To Be Something You Just Wrote. (8 ) .If you have any duplicate logic, or inexpressive code, refactor to remove duplication and increase expressiveness -. this includes reducing coupling and increasing cohesion (9) .Run the tests again, you should still have the Green Bar If you get. The red bar, the you name a mistake in you R Refactoring. Fix it now and re-run. (10) .repeat the steps above uteril you can set new code.ii-getting start ============================================================================================================================================================== ======
1.Preparation (1) .choose Right UnitTest Framework (uf) .the uf is Some Develop Tools with Which One Can Easily Create Tests, Orginaze The and View The FedBack. (2) .Setting Up Uf.using Uf to Perform Test. (3) .cppunit is a c unit testing framework. It started it................................ ..
(1) .Write a unit test that the system currently does not pass For example, to test the equality comparison for a MyComplex number class, write:. Class ComplexNumberTest: public CppUnit :: TestCase {public: ComplexNumberTest (std :: string Name): cppunit :: testcase (Name) {} void runtest () {cppunit_assert (Mycomplex (10, 1) == Mycomplex (10, 1)); cppUnit_assert (! (Mycomplex (1, 1) == Mycomplex (2 , 2)) ); } };
(2) .quickly Write The code to pass Test. In Order to Pass the Test Quickly, We Write a class named mycomplex. Class mycomplex {}; // if we compile now, We get compile error.so Keep fixing it. Bool Operator == (const mycomplex & a, const mycomplex & b) {RETURN TRUE;} // Now Compile It Again, OK! Run IT, We'll Get Some Fail. // this is Because The Operator == () DOESN ' T Work Properly.keep Fixing It. Class MyComplex {Friend Bool Operator == (Const Mycomplex & A, Const MyComplex & B); Double Real, Imaginary; Public: MyComplex (Double R, Double I = 0): Real (r), Imaginary (i) {}}; bool operator == (const mycomplex & a, const mycomplex & b) {return a.real == b.real && a.imaginary == B.Imaginary;} // if we compile now and weight Test it will pass. (3) .refactor the code to remove any duplication or other design Nasties // Here i Found TH e name "mycomplex" is not good, i change the name. (4) .move on to the next unit test // Now it worked ok.move to other cass.such as getMod (). .. (5). IrE Conta I Hold Cases. There'll Always Be More Test Case.so We Need To Organize The Into Some Friendly Format.here We Have CPPUnit :: TestFixTure To Hold A Lot of Test Cases. / / CODE BEGIN ... CLASS COMPLEXNUMBERTEST: PUBLIC CPPUNIT:: TestFixTure {Private: Complex * m_10_1, * m_1_1, * m_11_2; public: void setup () {m_10_1 = new complex (10, 1); m_1_1 =
New Complex (1, 1); M_11_2 = New Complex (11, 2);} void teardown () {delete m_10_1; delete m_1_1; delete m_11_2;} void testEquality () {cppUnit_astert (* m_10_1 == * m_10_1); cppunit_assert (! (* m_10_1 == * m_11_2));} void testaddition () {cppunit_assert (* m_10_1 * m_1_1 == * m_11_2);}}; // code end ... Also there is offen more Than Test FixTure , so we use CppUnit :: TestSuite to orginaze more than one "Fixture" // Code begin ... CppUnit :: TestSuite suite;. CppUnit :: TestResult result; suite.addTest (new CppUnit :: TestCaller
(1) .What can we do when the background is complicated? When we implement some components which relate to database or GUI, what can we do to test it? Mock Objects. What is mock objects? For example, when use a database for ? querying some data, what can we do if the database server is not ready yet We can give a simple class which implement the functions just simple and quick, then we can test our function locally.Below is the Definition about Mock Object - from www.mockobjects.com A mock object is a "double agent" used to test the behaviour of other objects. First, a mock object acts as a faux implementation of an interface or class that mimics the external behaviour of a true implementation. Second, a mock object observes how other objects interact with its methods and compares actual behaviour with preset expectations. When a discrepancy occurs, a mock object can interrupt the test and report the anomaly. If the discrepan cy can not be noted during the test, a verification method called by the tester ensures that all expectations have been met or failures reported What situation we should consider about using mock objects * The real object has nondeterministic behavior (it produces unpredictable results.?;
AS IN A Stock-Market Quote Feed.) * The Real Object Is Difcult To Set Up. * The Real Object Has Behavior That Is Hard To Trigger (for Example, A Network Error). * The Real Object Is Slow. * The Real object has (or is) a user interface. * The test needs to ask the real object about how it was used (for example, a test might need to check to see that a callback function was actually called). * The real object does not yet exist (a common problem when interfacing with other teams or new hardware systems) The three key steps to using mock objects for testing are:. 1. Use an interface to describe the object 2. Implement the interface for production code 3. Implement The interface in a mock object for testingiiii-resources =============
Wiki About TDD http://c2.com/cgi/wiki?TestDrivenDevelopmentUnittests in extremeprogramming.com http://www.extremeprogramming.org/rules/unittests.htmlUnittest Patterns http://www.codeproject.com/script/admentor/ INCLUDE / SERVEADHTML.ASPX? C = false & id = 786
