Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

All Done!!! #29

Merged
merged 1 commit into from
Jul 6, 2013
Merged

All Done!!! #29

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
54 changes: 27 additions & 27 deletions hudsonbook-content/src/main/resources/appa.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,7 @@
Tests</phrase></title>
<sect1 id="sect-testing-maven">
<title>Automating Your Tests with Maven</title>
<para>Maven<indexterm class="startofrange" id="appa-maven1" significance="normal"><primary>tests</primary><secondary>automating</secondary><tertiary sortas="Maven">with Maven</tertiary></indexterm><indexterm class="startofrange" id="appa-maven2" significance="normal"><primary>Maven</primary><secondary>automating tests</secondary></indexterm> is a popular open source build tool of the Java world, that
<para>Maven<indexterm class="startofrange" id="appa-maven1" significance="normal"><primary>tests</primary><secondary>automating</secondary><tertiary sortas="Maven">with Maven</tertiary></indexterm><indexterm class="startofrange" id="appa-maven2" significance="normal"><primary>Maven</primary><secondary>automating tests</secondary></indexterm> is a popular open source build tool in the Java world that
makes use of practices such as declarative dependencies, standard
directories and build life cycles, and convention over configuration to
encourage clean, maintainable, high level build scripts. Test automation
Expand Down Expand Up @@ -44,7 +44,7 @@ Tests run: 38, Failures: 0, Errors: 0, Skipped: 0</screen>
<para>In addition to executing your tests, and failing the build if any of
the tests fail, Maven will produce a set of test reports (again, by
default) in the <filename moreinfo="none">target/surefire-reports</filename> directory, in both XML
and text formats. For our CI purposes, it is the XML files that interest
and text formats. For our CI purposes, it's the XML files that interest
us, as Jenkins is able to understand and analyze these files for its CI
reporting:</para>
<screen format="linespecific">$ <userinput moreinfo="none">ls target/surefire-reports/*.xml</userinput>
Expand All @@ -58,23 +58,23 @@ target/surefire-reports/TEST-com.wakaleo.training.tweeter.domain.TweeterUserTest
large amount of test feedback in as little time as possible. Integration
tests are slower and more cumbersome, and often require the application to
be built and deployed to a server (even an embedded one) to carry out more
complete tests. Both these sorts of tests are important, and for a
well-designed Continuous Integration environment, it is important to be
complete tests. Both these sorts of tests are important. For a
well-designed CI environment, it is important to be
able to distinguish between them. The build should ensure that all of the
unit tests are run initially—if a unit test fails, developers should be
notified very quickly. Only if all of the unit tests pass is it worthwhile
undertaking the slower and more heavyweight integration tests.</para>
<para>In Maven, integration tests are executed during the <command moreinfo="none">integration-test</command> life cycle phase, which you can
invoke by running <literal moreinfo="none">mvn integration-test</literal> or (more simply)
<literal moreinfo="none">mvn verify</literal>. During this phase, it is easy to configure
<literal moreinfo="none">mvn verify</literal>. During this phase, it's easy to configure
Maven to start up your web application on an embedded Jetty web server, or
to package and deploy your application to a test server, for example. Your
integration tests can then be executed against the running application.
The tricky part however is telling Maven how to distinguish between your
The tricky part, however, is telling Maven how to distinguish between your
unit tests and your integration tests, so that they will only be executed
when a running version of the application is available.</para>
<para>There are several ways to do this, but at the time of writing there
is no official standard approach used across all Maven projects. One
<para>There are several ways to do this, but at the time of writing there's
no official standard approach used across all Maven projects. One
simple strategy is to use naming conventions: all integration tests might
end in “IntegrationTest”, or be placed in a particular package. The
following class uses one such convention:</para>
Expand Down Expand Up @@ -152,8 +152,8 @@ target/surefire-reports/TEST-com.wakaleo.training.tweeter.domain.TweeterUserTest
illustrated in <xref linkend="fig-hudson-testing-sample-project"/>, all
of the functional tests have been placed in a package called
<command moreinfo="none">webtests</command>. There's no constraint on the names of the
tests, but we are using Page Objects to model our application user
interface, so we also make sure that no classes in the
tests, but you're using Page Objects to model your application user
interface, so you also make sure that no classes in the
<command moreinfo="none">pages</command> package (underneath the
<command moreinfo="none">web</command><phrase role="keep-together"><command moreinfo="none">tests</command></phrase> package) are
treated as tests.</para>
Expand All @@ -168,7 +168,7 @@ target/surefire-reports/TEST-com.wakaleo.training.tweeter.domain.TweeterUserTest
</imageobject>
</mediaobject>
</figure>
<para>In Maven, we could do this with the following configuration:</para>
<para>In Maven, you could do this with the following configuration:</para>
<programlisting id="I_programlisting_d1e18488" format="linespecific"> &lt;plugin&gt;
&lt;artifactId&gt;maven-surefire-plugin&lt;/artifactId&gt;
&lt;configuration&gt;
Expand Down Expand Up @@ -207,7 +207,7 @@ target/surefire-reports/TEST-com.wakaleo.training.tweeter.domain.TweeterUserTest
&lt;/executions&gt;
&lt;/plugin&gt;</programlisting>
<para>TestNG currently has more flexible support for test groups than
JUnit. If you are using TestNG, you can identify your integration tests
JUnit. If you're using TestNG, you can identify your integration tests
using TestNG Groups. In TestNG, test classes or test methods can be tagged
using the <literal moreinfo="none">groups</literal> attribute of the
<literal moreinfo="none">@Test</literal> annotation, as shown here:</para>
Expand Down Expand Up @@ -257,7 +257,7 @@ public void cashWithdrawalShouldDeductSumFromBalance() throws Exception {
...</programlisting>
<calloutlist>
<callout arearefs="maven-it-ng-1">
<para>Do not run the integration-tests group during the test
<para>Don't run the integration-tests group during the test
phase.</para>
</callout>
<callout arearefs="maven-it-ng-2">
Expand All @@ -267,9 +267,9 @@ public void cashWithdrawalShouldDeductSumFromBalance() throws Exception {
</calloutlist>
<para>It often makes good sense to run your tests in parallel where
possible, as it can speed up your tests significantly (see <xref linkend="sect-tests-too-slow"/>). Parallel tests are particularly
intensive with slow-running tests that use a lot of IO, disk or network
access (such as web tests), which is convenient, as these are precisely
the sort of tests we usually want to speed up.</para>
intensive when doing lots of IO, disk, or network
access (such as web tests). These are precisely
the sort of tests you want to speed up.</para>
<para>TestNG provides good support for parallel tests. For instance, using
TestNG, you could configure your test methods to run in parallel on ten
concurrent threads like this:</para>
Expand All @@ -288,10 +288,10 @@ public void cashWithdrawalShouldDeductSumFromBalance() throws Exception {
<para>You can also set the <literal moreinfo="none">&lt;parallel&gt;</literal>
configuration item to <literal moreinfo="none">classes</literal> instead of
<literal moreinfo="none">methods</literal>, which will try to run the test classes in
parallel, rather than each method. This might be slower or faster,
parallel, rather than running each method serially. This might be slower or faster,
depending on the number of test classes you have, but might be safer for
some test cases not designed with concurrency in mind.</para>
<para>Mileage will vary, so you should experiment with the numbers to get
<para>You mileage will vary, so you should experiment with the numbers to get
the <indexterm id="I_indexterm_d1e18539" class="endofrange" startref="appa-maven1" significance="normal"><primary/></indexterm><indexterm id="I_indexterm_d1e18541" class="endofrange" startref="appa-maven2" significance="normal"><primary/></indexterm>best results.</para>
</sect1>
<sect1 id="sect-testing-ant">
Expand Down Expand Up @@ -335,16 +335,16 @@ public void cashWithdrawalShouldDeductSumFromBalance() throws Exception {
&lt;/target&gt;</programlisting>
<calloutlist>
<callout arearefs="junit-ant-1">
<para>We need to set up a classpath containing the <filename moreinfo="none">junit</filename> and <filename moreinfo="none">junit-ant</filename> JAR files, as well as the
<para>You need to set up a classpath containing the <filename moreinfo="none">junit</filename> and <filename moreinfo="none">junit-ant</filename> JAR files, as well as the
application classes and any other dependencies the application needs
to compile and run.</para>
</callout>
<callout arearefs="junit-ant-2">
<para>The tests themselves are run here. The
<literal moreinfo="none">haltonfailure</literal> option is used to make the build fail
immediately if any tests fail. In a Continuous Integration
environment, this is not exactly what we want, as we need to get the
results for any subsequent tests as well. So we set this value to
immediately if any tests fail. In a CI
environment, this isn't exactly what you want, as you need to get the
results for any subsequent tests as well. So, you set this value to
<literal moreinfo="none">no</literal> and use the <literal moreinfo="none">failureproperty</literal>
option to force the build to fail once all of the tests have
finished.</para>
Expand All @@ -356,19 +356,19 @@ public void cashWithdrawalShouldDeductSumFromBalance() throws Exception {
</callout>
<callout arearefs="junit-ant-4">
<para>The Junit Ant task can produce both text and XML reports, but
for Jenkins, we only need the XML ones.</para>
for Jenkins you only need the XML ones.</para>
</callout>
<callout arearefs="junit-ant-5">
<para>The <literal moreinfo="none">fork</literal> option runs your tests in a separate
JVM. This is generally a good idea, as it can avoid classloader issues
JVM. This is generally a good idea, as doing so can avoid classloader issues
related to conflicts with Ant’s own libraries. However, the default
behaviour of the JUnit Ant task is to create a new JVM for each test,
which slows down the tests significantly. The
<literal moreinfo="none">perBatch</literal> option is better, as it only creates one
new JVM for each batch of tests.</para>
</callout>
<callout arearefs="junit-ant-6">
<para>You define the tests you want to run in a fileset element. This
<para>Define the tests you want to run in a fileset element. This
provides a great deal of flexibility, and makes it easy to define
other targets for different subsets of tests (integration, web, and so
on).</para>
Expand Down Expand Up @@ -407,7 +407,7 @@ public void cashWithdrawalShouldDeductSumFromBalance() throws Exception {
&lt;/target&gt;</programlisting>
<para>TestNG is a very flexible testing library, and the TestNG task has
many more options than this. For example, to only run tests defined as
part of the “integration-test” group that we saw earlier, we could do
part of the “integration-test” group that you saw earlier, you could do
this:</para>
<programlisting id="I_programlisting_d1e18636" format="linespecific">&lt;target name="integration-test" depends="test-compile"&gt;
&lt;testng classpathref="test.classpath"
Expand All @@ -421,7 +421,7 @@ public void cashWithdrawalShouldDeductSumFromBalance() throws Exception {
&lt;/testng&gt;
&lt;fail message="TEST FAILURE" if="failed" /&gt;
&lt;/target&gt;</programlisting>
<para>Or to run your tests in parallel, using four concurrent threads, you
<para>Or, to run your tests in parallel, using four concurrent threads, you
<indexterm id="I_indexterm_d1e18643" class="endofrange" startref="appa-ant2" significance="normal"><primary/></indexterm><indexterm id="I_indexterm_d1e18645" class="endofrange" startref="appa-ant3" significance="normal"><primary/></indexterm>could do this:</para>
<programlisting id="I_programlisting_d1e18648" format="linespecific">&lt;target name="integration-test" depends="test-compile"&gt;
&lt;testng classpathref="test.classpath"
Expand Down
2 changes: 1 addition & 1 deletion hudsonbook-content/src/main/resources/ch02.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -857,7 +857,7 @@ To git@github.com:john-smart/game-of-life.git
you some more details about what went wrong (see <xref linkend="fig-new-job-failure-details"/>). Jenkins tells you that there
were 11 new test failures in this build, something which can be seen at a
glance in the <indexterm id="I_indexterm2_d1e2127" significance="normal"><primary>Test Result Trend graph</primary></indexterm>Test Result Trend graph—red indicates test failures. You can
even see which tests are failing, and how long they have been
even see which tests are failing, and how long they've been
broken.</para>
<figure float="none" id="fig-new-job-failure-details">
<title>The list of all the broken tests</title>
Expand Down
2 changes: 1 addition & 1 deletion hudsonbook-content/src/main/resources/ch07.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -128,7 +128,7 @@
</figure>
<para>If you click on a user in this list, Jenkins takes you to a page
displaying various details about this user, including the user’s full
name and the build jobs they have contributed to (see <xref linkend="fig-hudson-user-builds"/>). From here, you can also modify or
name and the build jobs they've contributed to (see <xref linkend="fig-hudson-user-builds"/>). From here, you can also modify or
complete the details about this user, such as their password or email
address.</para>
<figure float="none" id="fig-hudson-user-builds">
Expand Down
4 changes: 2 additions & 2 deletions hudsonbook-content/src/main/resources/ch08.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -336,7 +336,7 @@
has spotted the issue and is working on it. This avoids having more than
one developer waste time by trying to fix the same problem
separately.</para>
<para>The Claim plugin lets developers indicate that they have taken
<para>The Claim plugin lets developers indicate that they've taken
ownership of the broken build, and are attempting to fix it. You
install this plugin in the usual way. Once installed, developers can claim
a failed build as their own, and optionally, add a comment to explain the
Expand All @@ -349,7 +349,7 @@
this point on, you'll be able to claim a broken build in the build
details page (see <xref linkend="fig-hudson-notification-claim"/>).
Claimed builds will display an icon in the build history indicating that
they have been claimed. You can also make a build claim “sticky,” so that
they've been claimed. You can also make a build claim “sticky,” so that
all subsequent build failures for this job will also be automatically
claimed by this developer, until the issue is resolved.</para>
<figure float="0" id="fig-hudson-notification-claim">
Expand Down
2 changes: 1 addition & 1 deletion hudsonbook-content/src/main/resources/ch10.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1529,7 +1529,7 @@ Finished: SUCCESS</screen>
your web application to a test server, but only after it has passed a
number of automated functional and load tests. Or, you may want testers
to be able to flag certain builds as being ready for UAT deployment,
once they have completed their own testing.</para>
once they've completed their own testing.</para>
<para>The<indexterm id="I_indexterm10_d1e15589" significance="normal"><primary>plugins</primary><secondary>Promoted Builds</secondary></indexterm><indexterm id="I_indexterm10_d1e15594" significance="normal"><primary>Promoted Builds plugin</primary></indexterm> Promoted Builds plugin lets you identify specific builds
that have met additional quality criteria, and to trigger actions on
these builds. For example, you may build a web application in one build
Expand Down
6 changes: 3 additions & 3 deletions hudsonbook-content/src/main/resources/ch11.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -839,7 +839,7 @@
console (called GrandCentral). Click on the “Take me to Jenkins” button to
go to your brand new Jenkins master instance.</para>
<para>From here, your interaction with the DEV@cloud platform is exactly like
a standalone Jenkins instance. When you can create a new build job, just point
with a standalone Jenkins instance. When you create a new build job, just point
to your existing source code repository and hit build. DEV@cloud will
provision a slave for you and kick off a build (it may take a minute or
two for the slave to be provisioned).</para>
Expand All @@ -856,7 +856,7 @@
certain dedicated <phrase role="keep-together">machines</phrase>.</para>
<para>Once you start down the path of distributed builds, cloud-based
distributed build farms are a very logical extension. Putting your build
servers on the cloud makes it easier and more convenient to scale your
build infrastructure when required, as much as is <phrase role="keep-together">required</phrase>.</para>
servers in the cloud makes it easier and more convenient to scale your
build infrastructure when required, as much as <phrase role="keep-together">required</phrase>.</para>
</sect1>
</chapter>
Loading