SQL injection isn't the only type of exploit, of course, but it's worth a brief description as it's such an outrageously common—and easily avoided—form of attack. The attack, in a nutshell, is made possible when a search form is inserted directly into an SQL query; e.g., searching for hotels in Blackpool, the SQL query, constructed in your server code, would look something like this:

SELECT * FROM hotels WHERE city = 'Blackpool';

In the search form, the user would enter a town/city; the server component extracts this value from the submitted form, and places it directly into the query. The Java code would look something like this:

String city = form.getValue("city");
String query = "SELECT * FROM hotels WHERE city = '" + city + "';";

Giving effectively free access to the database opens up all sorts of potential for sneaky shenanigans from unscrupulous exploiters. All the user has to do is add his or her own closing single-quote in the search form, as in the following:

Blackpool'

Then the constructed query passed to the database will look like this:

SELECT * FROM hotels WHERE city = 'Blackpool'';

The database would, of course, reject this with a syntax error. How this is shown in the front-end is down to how you code the error handling—another "rainy day scenario" that must be accounted for, and have its own controller in the conceptual design and, therefore, its own test case.

But it's a simple task for the user to turn this into a valid query, by way of an SQL comment:

Blackpool'; --

This will be passed directly to the database as the following:

SELECT * FROM hotels WHERE city = 'Blackpool'; --';

Everything after the -- is treated as a comment, so the door to your data is now wide open. How about if the user types into the search form the following?

Blackpool'; DROP TABLE hotels; --

Your server-side code will faithfully construct this into the following SQL, and pass it straight to the database, which, in turn, will chug away without question, just following orders:

SELECT * FROM hotels WHERE city = 'Blackpool'; DROP TABLE hotels; --

Depending on how malicious the attacker is, he or she could wreak all sorts of havoc, or (worse, in a way) build on the "base exploit" to extract other users' passwords from the database. There's a good list of SQL Injection examples on http://unixwiz.net.^[60]

Protecting against this type of attack isn't simply a case of "sanitizing" the single-quotes, as this excludes valid names such as "Brer O'Hare," in which a quote is a perfectly valid character. Depending on which language/platform/database you're using, there are plenty of libraries whose creators have thought through all the possible combinations of "problem characters." The library function will escape these characters for you—e.g., MySQL has a built-in function, mysql_read_escape_string(). You just have to make sure you call one. Or even better, use bind variables and avoid the problem altogether.

But either way, make sure you write tests that confirm your application is immune from SQL injection attacks. For example, use Selenium (or directly use HttpClient in your JUnit test) to post a "malicious" form to the webserver, and then query the test database directly to make sure the attack didn't work.

Also keep an eye on the SANS "top cyber security risks" page,^[61] and keep thinking about tests you can write—which can usually be shared among projects or components—to verify that your system isn't vulnerable to these kinds of attacks.

Setting up a secure session for automated tests can be a bit of a drag, but usually you only have to do it once. It's worth doing, because it brings the test system much closer to being a realistic environment—meaning the tests stand a better chance of catching "real-life" problems before the system's released into the wild.

However, one issue with security is that of passwords. Depending how integrated your system is with Microsoft Exchange, LDAP, Single Sign-On (SSO), Windows (or Unix) logins, etc., there may be an issue with storing a "real" password so that the test code can log in as a user and run its tests. The answer is, of course, to set up a test account where the password is commonly known, and the test account has restricted access just to the test environment. The ability to do this will depend on just how co-operative your organization's network services team happens to be.

Table 11-1 describes the properties of each level of integration test.

They key characteristic of all three is that you don't use mock objects or stunt services to isolate the code. Instead, let the code run wild (so to speak), calling out to whatever services or databases it needs to. Naturally, these will need to be in a test environment, and the test data will need to be strictly controlled, otherwise you'll have no end of problems with tests breaking because someone's been messing with the test data.

These tests will need to be run separately from the main build: because they're so easily broken by other teams, you definitely don't want your build to be dependent on them working. You do want the tests to be run automatically, just not as often as the isolated tests. Setting them up to run once an hour, or even just nightly, would be perfectly fine.

Start by identifying and writing integration tests at the scenario level. These are "end-to-end" tests, as they involve the entire system running, from one end of a use case scenario to the other. ("Start-to-finish" might be a more apt description than "end-to-end"!) They also involve simulating a user operating the GUI—clicking buttons, selecting rows in a table, etc.; most importantly, they involve the code sending actual requests to actual remote systems. These are true integration tests, as they involve every part of all the finished components working together as one fully integrated system.

Usually, scenario-level integration tests are quite straightforward to write, once you know how. But on occasion they can be difficult to write, due to some technical quirks or limitations in the system or framework you're utilizing. In this case, don't "bust a gut" or grind progress to a halt while trying to implement them. Instead, move to the next level down.

Controller-level integration tests are exactly like the controller tests in Chapter 6: they're there to validate that the logical software functions identified during conceptual design have been implemented correctly—and remain implemented correctly. However, there's one key difference: the integration tests don't isolate the software functions inside a walled garden; they call out to external services, and other classes within the same system. This makes them susceptible to the problems we described at the start of this chapter, so you'd normally only write an integration test at the controller level if the software function in question is solely focused on making a remote call.

If there are any gaps in the fence left over, plug them up with unit-level integration tests. These are the most "zoomed-in" and the most focused of the tests.

Let's walk through the three levels, from the narrowest in scope up to the broadest.

You'll want to run tests in a specific sequence. Do that as a way of emulating the steps in a scenario.

Scenario-level tests have a lot in common with behavior-driven development (BDD), which also operates at the scenario level. In fact, BDD uses "scenario files," each of which describes a series of steps: the user does this, then the user does that... BDD scenarios are very close to use case scenarios, so close that it's possible to use BDD test frameworks such as JBehave or NBehave to implement DDT scenario-level integration tests.

Another possibility is to use a customer/business-oriented acceptance testing framework such as Fitnesse—essentially a collaborative wiki in which BAs and testers can define test scenarios (really, inputs and expected outputs on existing functions), which are then linked to code-level tests.

One final possibility, which xUnit purists will shoot us for suggesting, is—given JUnit and FlexUnit don't provide a mechanism for specifying the order that their test methods/functions are executed in—to write a single test function in your scenario test case, which then makes a series of function calls, each function mapping to one step in your use case scenario.

Databases are possibly the most problematic aspect of integration testing. If your test searches for a collection of hotels balanced on a sandy island in the Maldives, the expectation that the same set of hotels will always be returned might not remain correct over time. It's a reasonable expectation: a test needs consistent, predictable data to check against its expected results. However, who's to say that another team won't update the same test database with a new set of hotels? Your test will break, due to something outside your team's control.

A list of hotels should be fairly static, but the problem can be exacerbated when the data is more dynamic, e.g., client account balance. Your test might perform an operation that updates the balance; the next step will be to query the database to return the correct balance, but in that moment someone else's test runs, which changes the balance to something else—pulling the rug out from beneath the feet of your own test. Data contention with multiple tests running against a shared database is, as you'd expect, unpredictable: not good for a repeatable test.

One particularly tempting answer is to isolate a copy of the database for your own tests. This may or may not be practicable, depending on the size of the database, and how often it's updated. Each time someone adds a new column to a table, or inserts a new foreign key, every test instance of the database, on each developer's PC and the testers' virtual desktops, would need to be updated.

A simple answer is to run the integration tests less often, and only run them from one location—a test server that's scheduled to run the integration tests each night at 1 a.m., say. In fact, this is a fairly vital setup for integration tests. They just can't be run in the same "free-for-all" way that unit tests are run.

But there's still the problem that the database may not be in a consistent state at the start of each test.

From a data perspective, think of each integration test as a very large unit test: self-contained, affecting a limited/bounded portion of the overall database. Just as a unit test initially sets up its test fixtures (in the setUp() method), so an integration test can prepare the database with just the data it needs to run the test: a restricted set of hotels and their expected amenities, for example.

For example, the following method (part of the Hotel class) calculates the overall cost of staying at a hotel over a number of nights (ignoring complications like different prices for different nights during the stay):

public double calculateCostOfStay(int numberOfNights, String discountCode) {
    double price = getPricePerNight(new Date());
    double discount = getDiscount(discountCode);
    return (price * numberOfNights) - discount;
}

We could test this method of Hotel with the following JUnit code:

@Test
public void calculateCostOfStay() throws Exception {
    Hotel hotel = HotelsDB.find("Hilton", "Dusseldorf");
    double cost = hotel.calculateCostOfStay(7, "VRESORTS SUPERSAVER");
    assertEquals(1300, cost, 1e-8);
}

This code attempts to find a hotel from a live connection to the test database, and then calls the method we want to test. There's a pretty big assumption here: that the rooms will cost $200 per night, and that there's an applicable discount code that will produce a $100 discount (resulting in a total cost of stay for seven consecutive nights of $1300). That might have been correct when the test was written; however, you'd expect the database to be updated at random times, e.g., the QA team might from time to time re-inject it with a fresh set of data from the production environment, with a totally different set of costs per night, discount codes, and so on.

To get around this problem, your integration test's setup code could prepare the test data by actually writing what it needs to the database. In the following example, JUnit's @BeforeClass annotation is used so that this setup code is run once for the whole test case (and not repeatedly for each individual test method):

@BeforeClass
public static void prepareTestData() throws Exception {
    Hotel hotel = HotelsDB.findOrCreate("Hilton", "Dusseldorf");
    hotel.setPricePerNight(200.00);
    hotel.addDiscount(100.00, "VRESORTS SUPERSAVER");
    hotel.save();
}

As long as it's a fair bet that other people won't be updating the test database simultaneously (e.g., run your integration tests overnight), this is an easy, low-impact way of ensuring that the test data is exactly what that precise test needs, updated "just-in-time" before the test is run.

This approach keeps the amount of setup work needed to a minimum, and, in fact, makes the overall task much less daunting than having to keep an entire database in a consistent and repeatable state for the tests.

We'll run through a quick example using one of the scenarios (or "use case threads") from the Mapplet—specifically, the basic course for Advanced Search. Here it is as a quick reminder:

We want to write an automated scenario test that will step through each step in the use case, manipulating the GUI and validating the results as it goes along. Ultimately we're interested in the end-result displayed on the screen, based on the initial input; but a few additional checks along the way (without going overboard, and as long as they don't cause the test to delve too deeply inside the product code) are worth doing.

An xUnit test class is the simplest way to implement a scenario test, being closest to the code—therefore, the test won't involve any additional files or setup. However, using a unit test is also the least satisfactory way, as it offers zero visibility to the customer, testers, and Business Analysts (BAs), all of whom we assume aren't programmers or don't want to be asked to roll their sleeves up and get programming.

The Mapplet scenario tests are implemented in FlexUnit, because the Flex client is where the UI action happens. So even though the system being tested does traverse the network onto a Java server, the actual interaction—and thus the scenario tests—are all Flex-based.

The scenario test for the Advanced Search basic course looks like this:

[Test]

public function useAddress_BasicCourse(): void {
    findLocalAOI();
    enableAdvancedSearchWidget();
    clickAdvancedSearchIcon();
    confirmAdvancedSearchWidgetExpanded();
    confirmFieldsPopulatedWithDefaults();

    enterReservationDetail();
    confirmValidationPassed();

    selectHotelFilterCriteria();
    clickFIND();
    confirmMatchingHotelsOnMap();
    confirmMatchingHotelsOnListWidget();
}

Notice how this covers each user-triggered step in the use case. For example, the clickAdvancedSearchIcon() function will programmatically click the Advanced Search icon, triggering the same event that would happen if the user clicked the icon.

We don't add additional steps for events that happen after the user has clicked a button, say, as these additional steps will happen as a natural consequence of the user clicking the button. However, we do include "confirm" functions, in which we assert that the UI is being shown as expected; e.g., confirmAdvancedSearchWidgetExpanded() does exactly that— it confirms that, in the UI, the "state" of the Advanced Search Widget is that it's expanded.

As we mentioned, this style of scenario test is the easiest for a developer to write and maintain, but you'll never get a customer or business analyst to pore over your test code and sign off on it—at least, not meaningfully. So (depending on the needs of your project) you might prefer to use a more "business-friendly" test framework, such as Fitnesse or one of the BDD frameworks.

Socket code that works perfectly on one PC with local loopback might fail unexpectedly when connecting over a network, simply because communication takes longer. The programmer might not have thought to include a "retry" function, because the code never timed out while running it locally. Similarly, he may not have included buffering, simply reading data until no more bytes are available (when more could still be on the way), because locally the data would always all arrive at once.

This is a good example of where struggling to create an integration test (and the test environment, with network-deployed middleware, etc.) can actually save time in the long run. Encountering these real issues in an end-to-end test means they'll be addressed during development, rather than later when the allegedly "finished" system is deployed, and discovered not to be working.

We touched on this in the previous section, but the problem of a database changing (tables being dropped or renamed, new columns added/renamed/removed, or their type being changed, foreign keys randomly removed, and so on) seems to have a particularly harsh effect on automated tests. Each time the database is changed, it's not just the product code that needs to be updated, but the tests that assume the previous structure as well.

Keeping your tests "black box" can help a lot here. In fact, as you'll see later, the only real way for integration tests to be viable is to keep them as "black box" as possible. Because their scope is much broader than myopic unit tests, they're susceptible to more changes at each juncture in the system they pass over. So the fewer assumptions about the system under test that are placed in the test code, the more resilient your integration tests will be to changes. In the case of database changes, this means not putting any "knowledge" of the database at all (column names, table names, etc.) in the tests, but making sure everything goes through a business domain-level interface.

Evolutionary development (as "agile" used to be known) has become rather popular, because it gives teams the excuse to design the system as they go along, refactoring services, interfaces, and data structures on the way.^[73] While the opposite antipattern (the rigid refusal to change anything once done) is also bad, being too fluid or agile can be highly problematic in a multi-team project. Team A publishes an interface that is consumed by team B's client module. Then team A suddenly changes their interface, breaking team B's module because team B had somehow forgotten that other teams were using their public interface. It happens all the time, and it slows development to a crawl because teams only find out that their (previously working) system has broken at the most inopportune moments.

Again, this will break an automated test before it breaks the "real" deployed product code. This may be regarded as an example of why automated integration tests are so fragile, but, in fact, it's another example of the automated tests providing an early warning that the real system will break if it's deployed in its current state.

It's to be expected that the remote system is under construction just as your client system is. So the team developing the other system is bound to have their fair share of teething troubles and minor meltdowns. A set of automated integration tests will find a problem straightaway, causing the tests to break—when, otherwise, the other team may have quietly fixed the problem before anyone even noticed. So automated tests can amplify integration issues, forcing teams to address a disproportionately higher number of problems. This can be viewed as a good or a bad thing depending on how full or empty your cup happens to be on that day. On the positive side, bugs will probably be fixed a lot quicker if they're discovered and raised much sooner—i.e., as soon as one of your tests breaks.

A "cloudy day" isn't a tangible problem—in fact, perhaps we're just feeling a bit negative after listing all these other problems! But there are definitely days when nothing on an agile project seems to fit together quite right—you know, those days when the emergent architecture emerges into a Dali-like dreamscape. Whole days can be wasted trying to get client module A to connect with and talk to middleware module B, Figure 11-5 being a case in point! If client module A happens to be test code, it's tempting to give up, deeming the test effort "not worth it," and return to the product code—storing up the integration issues for later.

With these problems in mind, it could be easy to dismiss integration tests as just too difficult to be worth bothering with. But that would be to miss their point—and their intrinsic value—entirely.

Figure 11-5. When it comes to integration, even the best software can have a cloudy day.