tal vez lo traduzca
Contractual Test-Driven Development (DBC with TDD) |
This article is written by Dave Chaplin, an IT Consultant with 10 years experience. He leads and mentors teams of developers on agile .NET projects and has extensive experience in agile development techniques, particularly Test-Driven Development. Dave can be emailed atdavechaplin@byte-vision.com.
Date: Tuesday, April 22, 2003
Abstract
Test Driven Development (TDD) is at the heart of Extreme Programming and is used to add significant quality to the programming process. It drives the development and ensures you only build what is required for a particular test case, rather than spending time developing the system for what ‘might be’ needed in the future. Productivity is enhanced since the system is continuously regression tested. Better design is achieved since writing the tests first helps to validate existing design decisions and refine and improve them.Design By Contract (DBC) was invented by Bertrand Meyer. It adds a significant quality aspect to the design and programming process. The technique enormously improves development productivity by ensuring that what is built conforms to the defined specification. It provides clients with a precise definition of the behaviour of a component. Integrating components becomes much less painful and code bloat is reduced by removing the amount of error checking code required.
The two techniques do have some overlap and also some areas of confliction. This article discusses effective ways to blend the two techniques to further increase quality, and thus productivity, in an agile development process.
Account Deposit with TDD
Below is an overview of the techniques.
In TDD we write a test before we actually write the code. The test sets up an initial condition (like creating an instance of something). We then run some code against it, and then assert that certain conditions are true. It works like this:
Step 1: Write the test: Set up an initial condition and write some test code against it with some assertions.
Lets say I want to write an account object and then be able to deposit money into my account. Yep, our good ole friend the account object has popped up again. My test code, written using NUnit 2.0 would look something like this:
Note that, in order to be able to test the Deposit method on the Account object I needed to have a Balance property. Thus, TDD has driven out a design decision. I still haven’t written the account object yet, which is why I have the blue wiggly lines indicating it will not compile.
Step 2: Get the test to compile: To get things compiling I create an account class that does nothing, but adheres to the interface defined in the test:
[I have also added the ‘using Domain;’ line to the test class to get it to compile.]
So, now when we run the test in NUnit we get a red light because the assertion fails.
Step 3: Code until the test passes: All we do now is complete the code until the test passes:
Now, when we run the test we get a green light and we know we have completed the code.
Granted, there are some gaps in the code at this point: what happens if I try to deposit a negative amount? Well, lets say that if we try to deposit a negative amount then an exception should be thrown. [We shouldn’t really be throwing expections for business rule failures which are not exceptional circumstances, but it will help illustrate some ideas.]. The test looks like this:
I’ve thrown an application expection here, but you could define expections that are more meaningful. This test fails, so we now write the code to pass the test:
The tests now pass. There are also some additional questions you could ask. For example, can I have an overdraft? Well, if we think in terms of TDD, the only requirement we have at the moment is to deposit an amount, and we have achieved that, so we move on. That is the essence of TDD with XP. Build only what you need now. If we need to enhance things later then we will do so. We will also refactor to change the design when required, with the comfort of a suite of tests that tell us if we have broken anything.
Lets now look at how things would turn out using DBC.
Account Deposit with DBC
DBC is all about 3 things:
preconditions : things that must be true before we invoke a method.
postconditions : things that must be true after a method is invoked.
Invariants: things that must be true both before and after a method is invoked.
postconditions : things that must be true after a method is invoked.
Invariants: things that must be true both before and after a method is invoked.
For our account object withdraw method we could state the following DBC rules:
Account::Deposit(decimal depositAmount)
Pre : depositAmount > 0
Post : Account.Balance = Account.Balance@pre + depositAmount
Inv : Balance > 0
Post : Account.Balance = Account.Balance@pre + depositAmount
Inv : Balance > 0
For the sake of this example, I’ve just invented a requirement here that says you have no overdraft facility. This then means I have an invariant which states that the balance must always be positive.
Note also the use of the ‘@pre’ symbol. This means the value of the property before the body of the method call was invoked.
Now, lets see what this looks like in code:
C#.Net does not have DBC support built in so I’ve had to write ‘@pre’ values to local variables at the start of the method body that can be used later in the method. This is a pain.
The DBC class has a bunch of methods that simply check the assertion passed and throw an exception with the passed message if the assertion fails. You might want to define different DBC exception types if you wish to distinguish between the varying types.
I’ve not written any code to roll back the transaction if the post or invariant checks failed. This is not required, since the DBC checks are compiled out for the release version. In DBC the client (calling code of this method) is responsible for ensuring that it adheres to the precondition before it calls the method. If the client illegally calls the supplier, then the supplier makes no promises about what will happen. The behaviour is essentially undefined. This removes the need to put lots of exception catching code in the client. If you wish to leave the DBC checks in at run time you can, but if one fails there is no much you can do about anyway. The system has a fault, and needs to be fixed.
Comparison of TDD and DBC
Both sets of code using TDD and DBC pass the tests.
During TDD we design for the specific (what we are building now) whereas in DBC we think more generally about the object itself regardless of who uses it. The focus is wider. The two methods conflict. With TDD we have a very narrow focus, which enables us to quickly build what is required now, whereas with DBC we have a danger to wander off into the ‘what if’ cases.
If the methods require precondition checks then TDD requires you to write a test for each condition which can result in an exponential explosion of tests when the number of preconditions increases. You also need tests for the edge cases. With DBC you don’t get that explosion at all since the precondition deals with the general case. The same argument can be used for invariant checking.
Because you are continuously testing TDD builds extra quality into the programming process by ensuring that breaks in the code do not occur as changes are introduced. DBC does not give you that comfort, although you may well have an automated test harness you can run. With TDD, the harness pops out as part of the process.
Using DBC precondition checks and the DBC method means that client code does not have to check for exceptions thrown due to preconditions failing. With the way I’ve used TDD it means the client code has to be aware of the exceptions that can be raised. Granted, this is a weak argument, since you could turn off the precondition checks in TDD for production code.
Both TDD and DBC force design decisions to ensure client code can check a methods preconditions before it is called. This is good design, which ensures that the calling code can change it’s behaviour if the supplier is not going to pass the preconditions. For example, rather than trying to withdraw a negative amount the user could be redirected to an area of the application that offers the ability to apply for a loan. This is more powerful than trying to capture an exception then change the behaviour based on that exception. Although the last statement is more to do with using exceptions for the right purpose than TDD and DBC driving the proper use of exceptions.
So, given the above arguments, and my experience of using the two techniques together I believe the techniques I describe below effectively combine TDD and DBC into what I loosely call Contractual Test Driven Development (CTDD).
Contractual Test Driven Development (CTDD)
The follow points below are guidelines for doing contractual test driven development.- Do not write tests for negative behaviour. Use a DBC precondition check instead which can be compiled out at run time.
- Use post condition checks if you want, but don’t re-write the whole body of code. [ if you work with a DBC supported language, like Eiffel.Net, I would suggest using full DBC and derive generalised post conditions from your TDD assertions. This is just an idea though, I’ve not actually tried it in practice. It could reduce the amount of test code.]
- Use Post conditions where you can without re writing the whole body, or have to then introduce a lot of code because your language does not support DBC.
- Turn off DBC checks for production if performance is an issue.
- Leave DBC checks in the code if the system is life critical.
Benefits of CTDD
The benefits from TDD are:- building only what is required now. Keep it simple and well focused.
- a suite of automated tests for effective refactoring, continuous integration and regression testing.
- Design decisions are driven from the tests.
- the code quality is higher due to the precondition checks.
- you do not need all the checking code in the production code which forces code bloat.
- design decisions are driven from the preconditions.
- cleaner code since there is no need for checking code in the method body.
CTDD In Practice
The CTDD technique was developed in practice, rather than theory, by an XP team that I am currently leading. We started with some “interesting ideas” about how it could be done, some of which were clearly flawed when it came to actually trying them out. The methods I describe herein are now practiced by the team wholeheartedly and we have found that adding DBC to the TDD equation has significantly increased the quality of the code, particularly the refactoring and debugging activities.
A sincere acknowledgement goes to Duncan Green, who helped develop and practice these ideas during the agile development at Freshfields Bruckhaus Deringer. Duncan is a superb technician and designer, and pragmatist who has a shared interest good design and high quality.Closing Comments (A Dose of Reality)
Whilst I’ve coined the phrase CTDD here, I’m certainly not going to try and pretend that I’ve invented something new, by any stretch of the imagination. TDD, DBC and the use of assertions were invented years ago. What I’ve described in this article are observations of how, in practice, I’ve personally managed to combine the techniques.Happy developing (not debugging!).
Dave Chaplin
Last time, I introduced the topics of TDD and DBC. These techniques lead you to:
I have noted the classes and methods that I will show assertions for:
In some complex portions of the design, CodePro cannot figure out how to create valid instances for the test fixtures. In this case, you can provide a <className>Factory class in the<projectName>Test project with static methods that return valid instances. You find these situations when you encounter aNullPointerException when running a test case and the test fixture has null(s) in its logic.
Assertions are entered into our modeling tool, such as MagicDraw, as comments on the classes (for invariants) and methods (for pre and post conditions). These are carried over to our IDE (Eclipse in this case) as JavaDocs. The assertions can be edited or entered in the IDE as needed, with roundtrip engineering updating our model.
All our assertions are being tested. If we change them, we can just regenerate the affected objects (method, class, package, project).
CodePro and JUnit provide tools to run the test cases, see the results, fix any problems, rerun the tests, ... This supports TDD.
But that's not all: CodePro also will parse, run, and create test cases for existing code too:
From EmployeeEfficiencyReport.java (the concrete subclass chosen for this test case)
This has been a short (well, not that short) look at a process and tools to use TDD on your project in a way that makes you more productive, rather than a drag on productivity.
| 1 comments links to this post
@pre (boolean expression)
@post (boolean expression)
@inv (boolean expression)
Alright - that's a lot of information to digest before actually doing anything productive. In my next post, I'll introduce a tool to automate much of the heavy lifting, making TDD a real possibility on your project.
links.....................................
un link sobre TDD en DbC
un video de TDD en Dbd (en ingles)
Generate meaningful unit tests quickly & easily
Last time, I introduced the topics of TDD and DBC. These techniques lead you to:
- define what it is you are trying to build,
- create test cases to see if you are building what is required (and no more), and
- iteratively and incrementally verify that the code you are writing is correct.
Note: CodePro can create test cases for existing code too! It does a great job of testing based on your current design. It parses the code as well as actually running it to examine the behavior of your system. So, these techniques can be used with new or existing efforts.
CodePro works with Eclipse and uses JUnit. Both of these are free. For more information about JUnit, I recommend JUnit Recipes by Rainsberger.
UML Model
We are going to go through a relatively simple example of how to use CodePro to generate meaningful test cases for your designs. The package we are going to target is the event package, as shown in this Unified ModelingLanguage class diagram:
Note: if you don't know UML, I recommend Applying UML and Patternsby Larman and UML Distilled by Fowler. This diagram was created using MagicDraw, which is an excellent product.
I have noted the classes and methods that I will show assertions for:
- Loggable
The ability to take part in a SystemEvent.
@invariant (getEventString() != null && getEventString().length() > 0)
@invariant (getEvents() != null)
- Loggable.add()
Add anEvent to my events. Throw an Exception if anEvent is not one of my
validEventTypes.
@throws Exception
@post (getEvents().contains(anEvent))
- UpdateEvent()
Constructor
@throws Exception
@pre target instanceof Loggable
@pre EventType.contains( type )
@pre attributeName != null && attributeName.length() > 0
@pre oldValue != newValue
- SystemEvent.getType()
@return a String to uniquely indicate my type
@post ($ret == type)
In some complex portions of the design, CodePro cannot figure out how to create valid instances for the test fixtures. In this case, you can provide a <className>Factory class in the<projectName>Test project with static methods that return valid instances. You find these situations when you encounter aNullPointerException when running a test case and the test fixture has null(s) in its logic.
Process
The process we will follow looks like this:
Assertions are entered into our modeling tool, such as MagicDraw, as comments on the classes (for invariants) and methods (for pre and post conditions). These are carried over to our IDE (Eclipse in this case) as JavaDocs. The assertions can be edited or entered in the IDE as needed, with roundtrip engineering updating our model.
The generated test cases
We then use CodePro to generate test cases from our Java code. Here's some of what we'd get for LoggableTest:/**
* Return an instance of the class being tested.
* @return an instance of the class being tested
* @see Loggable
* @generatedBy CodePro at 1/18/06 1:33 PM
*/
public Loggable getFixture7()
throws Exception
{
if (fixture7 == null) {
fixture7 = new TestOrder(...);
}
return fixture7;
}/**
* Return an instance of the class being tested.
* @return an instance of the class being tested
* @see Loggable
* @generatedBy CodePro at 1/18/06 1:33 PM
*/
public Loggable getFixture8()
throws Exception
{
if (fixture8 == null) {
fixture8 = new Specimen( SpecimenNumberFactory.sampleSpecimenNumber(), new PatientRole(PersonFactory.heathcliffPeterman()...);
}
return fixture8;
}
/**
* Run the void add(SystemEvent) method test.
*
* @targetAssertion @post (getEvents().contains(anEvent))
* @targetAssertion @invariant (getEvents() != null)
* @targetAssertion @invariant (getEventString() != null && getEventString().length() > 0)
* @generatedBy CodePro at 2/24/06 10:57 AM
*/
public void testAdd_fixture28_5() throws Exception {
Loggable fixture = getFixture28();
SystemEvent anEvent = new UpdateEvent("Anäßt-1.0.txt", (Loggable) null, "Anäßt-1.0.txt", "Anäßt-1.0.txt", "Anäßt-1.0.txt");
fixture.add(anEvent);
// add test code here
assertTrue(fixture.getEvents().contains(anEvent));
assertTrue(fixture.getEvents() != null);
assertTrue(fixture.getEventString() != null && fixture.getEventString().length() > 0);
}Note that both concrete implementors of Loggable (TestOrder and Specimen) are used as fixtures! Also note that, when available, our factory static methods are used.All our assertions are being tested. If we change them, we can just regenerate the affected objects (method, class, package, project).
CodePro and JUnit provide tools to run the test cases, see the results, fix any problems, rerun the tests, ... This supports TDD.
But that's not all: CodePro also will parse, run, and create test cases for existing code too:
From EmployeeEfficiencyReport.java (the concrete subclass chosen for this test case)
/**
* Method getParameters.
* @return my parameters to my BIRT design
*/
protected HashMap getParameters() {
HashMap params = new HashMap();
params.put("department", department);
params.put("dateRange", dateRange);
return params;
}
From ReportTest.java
/**
* Return an instance of the class being tested.
* @return an instance of the class being tested
* @see Report
* @generatedBy CodePro at 2/24/06 11:36 AM
*/
public Report getFixture5() throws Exception
{
if (fixture5 == null) {
fixture5 = new EmployeeEfficiencyReport(new Department("", ""),
new DateRange(new GregorianCalendar(1999, 11, 31, 23, 59, 59),
new GregorianCalendar(1999, 11, 31, 23, 59, 59)));
}
return fixture5;
}
/**
* Run the java.util.HashMap getParameters() method test.
*
* @generatedBy CodePro at 2/24/06 11:36 AM
*/
public void testGetParameters_fixture5_1()
throws Exception
{
Report fixture = getFixture5();
java.util.HashMap result = fixture.getParameters();
// add test code here
assertNotNull(result);
assertEquals(2, result.size());
assertTrue(result.containsKey("dateRange"));
assertTrue(result.containsKey("department"));
}You can see that I didn't have any assertions - CodePro just parsed and ran the code and figured out what to test! How easy is that! (Hope you don't want to hold onto your old excuses for not unit testing adequately.)
CodePro Guidelines
As with any product, there are some lessons you learn along the way. These are mine, in no particular order:- Turn off the verification preference
Window / Preferences / CodePro / JUnit, Test Methods tab, Test Verification group - uncheck "Mark new test methods as unverified"
If verification is active, every test case will have a "fail(unverified)" line at the end. EPT does have a menu action to verify test cases so make it easy to eliminate these lines. Their thinking is that you should check out every test case to make sure it is doing the right thing. Considering that one class will have many test cases, I choose to take my chances with their generated code. I tend to look at a few of them, but nowhere near all of them.
- Keep the default preferences (other than ones specifically listed here).
This will result in a project namedTest with packages named exactly as those being tested. The classes in the packages are namedTest . Note: you must leave the "Design by Contract" options selected or else your test cases will not test your assertions!
- If you edit a test case, e.g. to add logic not generated for you, then you should delete the comment line that includes "@generatedBy CodePro".
This will keep CodePro from replacing that test case if another generate action is taken.
- If you have not edited test cases, delete the test class(es) before regenerating test cases.
This will make the generate action run much faster, since it doesn't have to check for edited logic that must be preserved.
- Before deploying, the code should be "uninstrumented" to remove unnecessary logic during production.
CodePro includes code coverage collection and reporting. Instantiations is able to collect coverage information because they "instrument" the code (add metric collection logic to the .class files).
- Create
Factory classes in theTest
project for cases where CodePro doesn't handle complex situations as well as you'd like.
If you have complicated business objects with nested compound collaborating objects, CodePro may use a meaningless String or even null for portions. If you create a factory class in the test project, CodePro will use it in the generated test cases. The factory class should be in the package with the same name as the real class' package and should have static methods (e.g. public static Person aCustomer() { ...} ) to return a valid instance. The Instantiations folks are working on enhancements that will flag when they had to use null.
- Generate test cases even if an Exception is thrown.
Preferences/CodePro/JUnit, Execution tab, "When an exception is thrown, generate a test method:", select "always". If you don't do this, you will have situations where you are scratching you head as to why there are no test cases generated for a class. When you select "always", you can run the tests, see the Exception and resolve the problem without having to guess what's wrong.
- Add or edit Design by Contract (DBC) tags if you have additional business rules you want tested or the DBC tags are erroneous. Instantiations is working on an enhancement to indicate when an assertion has invalid syntax (Eclipse ignores the assertions).
Tags should be in the same place you would put JavaDoc tags. The tags currently supported by CodePro are:
This tag is used to indicate a precondition, i.e. something that should be true (or false) upon entry to a method. This tag can only be used for methods. For example:
- @pre
@pre (aName != null && aName.length() > 0)
This tag is used to indicate a postcondition, i.e. something that should be true (or false) after a method executes. This tag can only be used for methods. For example:
- @post
@post specimens.contains( newSpecimen )
This tag is used to indicate something that should always be true (or false). This tag can only be used for classes. For example:
- @inv(ariant)
@inv (numEmployees >= 0)
The variables used within these tags' expressions currently supported by CodePro are:
This tag is used to test a return value. This tag can only be used for methods. For example:
- $ret
@post ($ret == type)
This tag makes use of a value upon entry to a method. This tag can only be used for methods. For example:
- $pre
@post count == $pre(int, count) + 1
This tag is used to check a non-void return from a method. This tag can only be used for non-void methods. For example:
- $result
@post ($result != null)
Note: Be careful how you specify assertions or EPT will generate compile errors in the test cases! Syntax checking of assertions in JavaDocs will be added in a future release. Until then, watch your parentheses, method name spelling, …
Troubleshooting
Symptom: You are getting a NullPointerException where you shouldn't.
Possible reason: You may need a Factory class. Look for nullin your fixture code to determine where.
Symptom: You don't get test cases where you should.
Possible reason: You might have a problem with a (super)class at load or construction time. Check static blocks, constructors, and variable initialization.
Symptom: There are errors in the test cases.
Possible reason: Your assertions may have a syntax error. Look at related pre, post, or invariant lines.
Symptom: All your test cases are failing, when some should pass.Possible reason: Make sure Preferences/CodePro/JUnit, Test Methods tab, Test Verification is unchecked. Alternatively, verify the test cases from the Test Case Outline view.
Symptom: Test results seem to be based on old code.
Possible reason: A class' source is out of sync with the binary file. If you have not edited the test case logic, delete the ClassNameTest class and regenerate it. If you have edited the test case logic, try forcing a rebuild of the Test project.
Labels: assertions, codepro, dbc, invariant, junit, postcondition,precondition, tdd, tips, unit test
| 1 comments links to this post
TDD using DBC
Test Driven Development usingDesign by Contract
TDD
Test-Driven Development Cycle in general involves these steps:- Write the test
- Write the code
- Run the automated test
- Refactor
- Repeat
Note: A good book on TDD is Agile Java by Langr.
DBC
Design by Contract has a history that goes back to the 1980s with work by Bertrand Meyer. The primary pragmatic idea we will use today is the concept of an assertion. There are three types of assertions:- Precondition
- Postcondition
- Invariant
Precondition
A precondition is a condition that must hold true before a method can be executed. The format is:Examples
- @pre !isCancelled()
This might be used to make sure an Order can be modified.
- @pre quantityOrdered > 0
This might be used to make sure an amount being Ordered is a positive integer.
Postcondition
A postcondition is a condition that must hold true after a method is executed. The format is:Examples
- @post ($ret == (inventory.contains(aProduct))
This can be read as "answer whether my inventory contains a product". It may be an assertion on the Business.sells( aProduct ) method.
- @post savingsAcct.getBalance() ==$pre(savingsAcct.getBalance()) - anAmount
This business rule checks to make sure that after theSavingsAccount.withdraw( anAmount ) method that the balance is debited correctly.
Invariant
An invariant is a condition that must always hold true for a class. The format is:Examples
- @inv balance >= 0.0
This would certainly be a rule for Accounts in a banking application.
- @inv number.length() == 9
This would be a rule for a SocialSecurityNumber class.
Development Process using TDD and DBC
To use the assertions we've been discussing, put them in as comments into your modeling tool or in JavaDocs in your IDE.
links.....................................
un link sobre TDD en DbC
un video de TDD en Dbd (en ingles)
pruebas que pasen. Si lo miramos desde un punto de vista práctico, no hacemos más que asegurarnos de que ese caso pasa, ¿qué tienes esto de malo?, ¿por qué deberíamos borrarlo o no usarlo si pasa?, ¿por qué debería estar prohibido?. Cuando escribimos código para hacer pasar un test, escribimos el código más simple que podemos pensar para hacer pasar la prueba, sin embargo, esto no tiene por qué conllevar que ese “código mínimo” solamente hace pasar ese test específico. Algunas personas que hacen TDD dicen que lo que habría que hacer es “romper el código” artificialmente para ver cómo la prueba falla y después “arreglarlo” para verla pasar. En mi opinión esto es una pérdida de tiempo y ganas de hacer que una buena práctica parezca una religión. (Incluso el diagrama de flujo en la wikipedia, no ve contradicción en escribir una prueba que pase 
)
