Do you know that you can publish documents directly from Google Docs ?.png)
.png)
.png)
Generate the code static {
// initialize (c, f) pairs
conversionTable.put(0, 32);
conversionTable.put(100, 212);
conversionTable.put(-1, 30);
conversionTable.put(-100, -148);
conversionTable.put(32, 90);
conversionTable.put(-40, -40);
conversionTable.put(-273, -459);
}
public void testCelsiusToFahrenheit () {
for (int c: conversionTable.keySet()) {
int f = conversionTable.get(c);
String msg = "" + c + "C -> " + f + "F";
assertEquals(msg, f, TemperatureConverter.celsiusToFahrenheit(c));
}
}
public void invalidCelsiusTemperature () {
try {
int f = TemperatureConverter.celsiusToFahrenheit(-274);
} catch (RuntimeException ex) {
if (ex.getMessage().contains("below absolute zero")) {
return;
}
else {
fail("Undetected temperature below absolute zero: " + ex.getMessage());
}
}
fail("Undetected temperature below absolute zero: no exception generated");}
.png)
throw new UnsupportedOperationException("Not yet implemented");
return (int)Math.round(celsius * 1.8 + 32);
Undetected temperature below absolute zero: no exception generated
That's because we are expecting an exception to be thrown if the temperature is below the absolute zero but our first attempt doesn't do that.
Let's add this condition, but we first need the ABSOLUTE_ZERO_C constant.
Right click on the TemperatureConverter Attributes compartment in the class diagram
Now
Add the absolute zero check
if (celsius < ABSOL?UTE_ZERO_C) {
throw new RuntimeException("Invalid temperature: " + celsius + " below absolute zero");
}
return (int)Math.round(celsius * 1.8 + 32);
.png)
.png)
Patch
| Actor Action | System Response |
| 1. The user enters a temperature in Celsius, and then press Convert | 2. The system converts the temperature to Fahrenheit and the result is presented to the user |
| 3. The user wants to enter another temperature and continues from 1 or presses Close to exit. | 4. The process finishes. |
| Alternative Courses | |
| Temperature is below absolute zero | Indicate error |
| Invalid input characters entered | Indicate error |
We will use Netbeans 6 IDE to develop a very simple application (Temperature Converter: lets you convert temperatures in different units, pretty obvious duhh...) presenting a swing GUI which is our testing target. As usual JUnit is used for the testing infrastructure and Jemmy for the GUI components.
The domain can be restarted using the asadmin start-domain command. In order to restart the domain: |
|
Briefly, Test Driven Development is the strategy of starting the development process by the test cases and then provide the software that satisfies these tests, not the other way around.
Maybe you have been already charmed by the Test Driven Development and its innumerable virtues.
If not, I strongly recommend that you take a look at Wikipedia's (http://en.wikipedia.org/wiki/Test_driven_development) which is a good place to start and has a lot of external links.
The following UML activity diagram depicts the Test Driven Development process.
Start writing the tests, run the tests to verify that the test you have just written fails, write the code that satisfies it and the refactor the code to keep it tidy, clean an minimal.
Personally, the main advantage I've seen so far is that you focus your destination quickly and is much difficult to divert implementing options in your software that will never be used and wasting your precious time so much needed in order to arrive to the end of the project on time. To cut short what could be a very long story, I don't want to debate now if Test Driven Development could be applied to any project. I think that, as well as any other technique, you should use your judgment and expertise to recognize where it can be applied and where not. But having this in mind: there's no silver bullets.
Unit is the portion of your software being tested. You should also apply your experience to determine, in each case, what a unit can be. Sometimes it is a class, a set of classes or even a a method. In general, the tools are called xUnit where x is your favorite language (Java, Python, C++, VisualBasic).
Tests are composed into suites. Suites are a convenient way to keep related tests together and simplifies running all of the tests in every iteration of the process. Normally, all of the tests should be run to verify that nothing else is broken.
We will be using a python example. Also, assume that we have already written some tests classes stubs containing some tests placeholders. These classes are ATest, BTest and CTests, each in its corresponding module inside the tests subdirectory. These will help to maintain the separation between code and tests. They will test the correctness of classes A, B and C respectively.
#! /usr/bin/python
import sys
import unittest
class ATest(unittest.TestCase) :
def test1(self) :
self.assertEqual(1, 1)
def test2(self) :
self.assertEqual(1, 1)
if __name__ == '__main__':
unittest.main()
The same for the other classes.
In python, when you are writing a test driver you write something like this
#! /usr/bin/env python
import sys
import unittest
from tests.ATest import ATest
from tests.BTest import BTest
from tests.CTest import CTest
from tests.moretests.DTest import DTest
if __name__ == '__main__':
unittest.main()
This is a test driver that imports some classes to be tested, and the unittest discovers all of the test cases using introspection.
Nevertheless, there are some drawbacks with this approach:
Thus, we will try to address this problems creating a generic test driver, independent from the project we are working on, and this driver will generate automatically the Test suite accordingly to a given pattern of classes and a path to look for the modules.
With all of this in mind, we try our second driver. This driver uses the function find which emulates partially the behavior of the Unix find command (see downloads).
#! /usr/bin/env python
import sys
import os
import re
import unittest
from find import find
def loadTestsFromPath(dir='.', pattern='*Test.py', maxdepth=None) :
modules = []
for f in find(dir, pattern, maxdepth) :
mo = os.path.basename(f)[:-3]
mp = re.sub('^\./?', '', os.path.dirname(f)).replace(os.sep, '.')
if mp:
mp += '.'
modules.append(mp+mo)
return modules
if __name__ == '__main__':
ts = unittest.TestSuite()
for m in loadTestsFromPath('.') :
ts.addTests(unittest.TestLoader().loadTestsFromName(m))
unittest.TestProgram(defaultTest='ts')
Now the situation is much better
We still need some improvements, but it is pretty usable right now. The possible improvements are
These improvements will be the subject of the next part: Pyhton and Test Driven Development - Part II
