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

Fix typos and phrasing in documentation #136

Merged
merged 1 commit into from
Nov 10, 2017
Merged

Fix typos and phrasing in documentation #136

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
18 changes: 9 additions & 9 deletions docs/additional-features.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -34,14 +34,14 @@ want to test how others (people, or other programs) interact with the
application. Typically, you want to make sure that every use case and
execution path is fully tested. Third parties can interact with your
application in a number of ways, for example web services, remote EJBs
or via http. You need to check that you object serialization or
or via HTTP. You need to check that your object serialization or
networking work for instance.

This is why Arquillian comes with two run modes, `in container` and
`as client`. `in container` is to test your application internals and
`as client` is to test how your application is used by clients. Lets
`as client` is to test how your application is used by clients. Let's
dive a bit deeper into the differences between the run modes and see how
they effect your test execution and packaging.
they affect your test execution and packaging.

[[container-mode]]
===== Container mode: @Deployment(testable = true)
Expand Down Expand Up @@ -96,11 +96,11 @@ public class LocalRunServletTestCase {
It is also possible to mix the two run modes within the same test class.
If you have defined the `Deployment` to be testable, you can specify the
`@Test` method to use run mode `as client` by using the `@RunAsClient`
annotation. This will allow two method within the same test class to run
in different modes. This can be useful if you in a run `as client` mode
want to execute against a remote endpoint in your application, for then
in the next test method assert on server side state the remote endpoint
might have created.
annotation. This will allow two methods within the same test class to run
in different modes. This can be useful if, in `as client` mode, you
want to execute against a remote endpoint in your application, and then
in the next test method, use `in container` mode to verify some state
the previous remote invocation created on the server side.

[source,java]
----
Expand All @@ -120,7 +120,7 @@ public void shouldBeAbleToRunOnClientSide() throws Exception {
}
----

The effect of the different run modes depend on the
The effect of the different run modes depends on the
`DeployableContainer` used. Both modes might seem to behave the same in
some Embedded containers, but you should avoid mixing your internal and
external tests. One thing is that they should test different aspects of
Expand Down
2 changes: 1 addition & 1 deletion docs/containers.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -28,7 +28,7 @@ container.
_So what is the container that Arquillian uses? Is it some proprietary testing
container that emulates the behavior of the technology (Java EE)?_

Nope!It's pluggable. It can be your target runtime, such as JBoss AS,
Nope! It's pluggable. It can be your target runtime, such as JBoss AS,
GlassFish or Tomcat. Or it can even been an embedded container such as
OpenEJB, GlassFish Embedded or Weld SE. You can even use one container
for development and another for continuous integration.
Expand Down