Java Reference
In-Depth Information
We divide the lifecycle into the following platforms:
Development platform —This is where coding happens, on developers' worksta-
tions. One important rule is usually to commit (aka check in), up to several
times per day, to your Source Control Management ( SCM ) system ( SVN , CVS ,
ClearCase, and the like). Once you commit, others can begin using your work.
But it's important to commit only something that “works.” To ensure this, you
run a local build with Ant or Maven. You can also watch the results of an auto-
mated build based on the latest changes to the SCM repository (see chapters 9,
10, and 11.)
Integration platform —This platform builds the application from its various com-
ponents (which may have been developed by different teams) and ensures
that they all work together. This step is extremely valuable, because problems
are often discovered here. It's so valuable that we want to automate it. It's
then called continuous integration (see http://www.martinfowler.com/articles/
continuousIntegration.html) and can be achieved by automatically build-
ing the application as part of the build process (more on that in chapter 11
and later).
Acceptance platform/stress test platform —Depending on the resources available to
your project, this can be one or two platforms. The stress test platform exercises
the application under load and verifies that it scales correctly (with respect to
size and response time). The acceptance platform is where the project's cus-
tomers accept (sign off on) the system. It's highly recommended that the sys-
tem be deployed on the acceptance platform as often as possible in order to get
user feedback.
(Pre-)production platform —The preproduction platform is the last staging area
before production. It's optional, and small or noncritical projects can do with-
out it.
We now show how testing fits in the development cycle. Figure 5.6 highlights the dif-
ferent types of tests you can perform on each platform.
On the development platform , you execute logic unit tests (tests that can be exe-
cuted in isolation from the environment). These tests execute quickly, and you
usually execute them from your IDE to verify that any change you've brought to
the code has not broken anything. They're also executed by your automated
build before you commit the code to your SCM . You could also execute integra-
tion unit tests, but they often take much longer, because they need some part of
the environment to be set up (database, application server, and the like). In
practice, you'd execute only a subset of all integration unit tests, including any
new integration unit tests you've written.
The integration platform usually runs the build process automatically to pack-
age and deploy the application and then executes unit and functional tests.
 
 
Search WWH ::




Custom Search