Polishing

framework-docs/modules/ROOT/pages/testing/mockmvc/htmlunit/geb.adoc

@@ -8,9 +8,9 @@ use https://www.gebish.org/[Geb] to make our tests even Groovy-er.
 == Why Geb and MockMvc?
 
 Geb is backed by WebDriver, so it offers many of the
-xref:testing/mockmvc/htmlunit/webdriver.adoc#mockmvc-server-htmlunit-webdriver-why[same benefits] that we get from
-WebDriver. However, Geb makes things even easier by taking care of some of the
-boilerplate code for us.
+xref:testing/mockmvc/htmlunit/webdriver.adoc#mockmvc-server-htmlunit-webdriver-why[same benefits]
+that we get from WebDriver. However, Geb makes things even easier by taking care of some
+of the boilerplate code for us.
 
 [[mockmvc-server-htmlunit-geb-setup]]
 == MockMvc and Geb Setup
@@ -28,7 +28,8 @@ def setup() {
 ----
 
 NOTE: This is a simple example of using `MockMvcHtmlUnitDriverBuilder`. For more advanced
-usage, see xref:testing/mockmvc/htmlunit/webdriver.adoc#mockmvc-server-htmlunit-webdriver-advanced-builder[Advanced `MockMvcHtmlUnitDriverBuilder`].
+usage, see
+xref:testing/mockmvc/htmlunit/webdriver.adoc#mockmvc-server-htmlunit-webdriver-advanced-builder[Advanced `MockMvcHtmlUnitDriverBuilder`].
 
 This ensures that any URL referencing `localhost` as the server is directed to our
 `MockMvc` instance without the need for a real HTTP connection. Any other URL is
@@ -62,10 +63,10 @@ forwarded to the current page object. This removes a lot of the boilerplate code
 needed when using WebDriver directly.
 
 As with direct WebDriver usage, this improves on the design of our
-xref:testing/mockmvc/htmlunit/mah.adoc#mockmvc-server-htmlunit-mah-usage[HtmlUnit test] by using the Page Object
-Pattern. As mentioned previously, we can use the Page Object Pattern with HtmlUnit and
-WebDriver, but it is even easier with Geb. Consider our new Groovy-based
-`CreateMessagePage` implementation:
+xref:testing/mockmvc/htmlunit/mah.adoc#mockmvc-server-htmlunit-mah-usage[HtmlUnit test]
+by using the Page Object Pattern. As mentioned previously, we can use the Page Object
+Pattern with HtmlUnit and WebDriver, but it is even easier with Geb. Consider our new
+Groovy-based `CreateMessagePage` implementation:
 
 [source,groovy]
 ----

framework-docs/modules/ROOT/pages/testing/mockmvc/htmlunit/mah.adoc

@@ -7,8 +7,7 @@ to use the raw HtmlUnit libraries.
 [[mockmvc-server-htmlunit-mah-setup]]
 == MockMvc and HtmlUnit Setup
 
-First, make sure that you have included a test dependency on
-`org.htmlunit:htmlunit`.
+First, make sure that you have included a test dependency on `org.htmlunit:htmlunit`.
 
 We can easily create an HtmlUnit `WebClient` that integrates with MockMvc by using the
 `MockMvcWebClientBuilder`, as follows:

framework-docs/modules/ROOT/pages/testing/mockmvc/htmlunit/webdriver.adoc

@@ -259,9 +259,11 @@ Kotlin::
 ======
 --
 
-This improves on the design of our xref:testing/mockmvc/htmlunit/mah.adoc#mockmvc-server-htmlunit-mah-usage[HtmlUnit test]
-by leveraging the Page Object Pattern. As we mentioned in <<mockmvc-server-htmlunit-webdriver-why>>, we can use the Page Object Pattern
-with HtmlUnit, but it is much easier with WebDriver. Consider the following
+This improves on the design of our
+xref:testing/mockmvc/htmlunit/mah.adoc#mockmvc-server-htmlunit-mah-usage[HtmlUnit test]
+by leveraging the Page Object Pattern. As we mentioned in
+<<mockmvc-server-htmlunit-webdriver-why>>, we can use the Page Object Pattern with
+HtmlUnit, but it is much easier with WebDriver. Consider the following
 `CreateMessagePage` implementation:
 
 --

framework-docs/modules/ROOT/pages/testing/mockmvc/htmlunit/why.adoc

@@ -60,7 +60,7 @@ assume our form looks like the following snippet:
 	</form>
 ----
 
-How do we ensure that our form produce the correct request to create a new message? A
+How do we ensure that our form produces the correct request to create a new message? A
 naive attempt might resemble the following:
 
 [tabs]
@@ -154,7 +154,7 @@ validation.
 [[mockmvc-server-htmlunit-why-integration]]
 == Integration Testing to the Rescue?
 
-To resolve the issues mentioned earlier, we could perform end-to-end integration testing,
+To resolve the issues mentioned above, we could perform end-to-end integration testing,
 but this has some drawbacks. Consider testing the view that lets us page through the
 messages. We might need the following tests:
 
@@ -171,7 +171,7 @@ leads to a number of additional challenges:
 * Testing can become slow, since each test would need to ensure that the database is in
   the correct state.
 * Since our database needs to be in a specific state, we cannot run tests in parallel.
-* Performing assertions on such items as auto-generated IDs, timestamps, and others can
+* Performing assertions on items such as auto-generated IDs, timestamps, and others can
   be difficult.
 
 These challenges do not mean that we should abandon end-to-end integration testing