From d178930186c630d4df858cf87b098b63d69084c8 Mon Sep 17 00:00:00 2001 From: Sam Brannen <104798+sbrannen@users.noreply.github.com> Date: Wed, 19 Nov 2025 17:05:32 +0100 Subject: [PATCH] Polishing --- .../pages/testing/mockmvc/htmlunit/geb.adoc | 17 +++++++++-------- .../pages/testing/mockmvc/htmlunit/mah.adoc | 3 +-- .../testing/mockmvc/htmlunit/webdriver.adoc | 8 +++++--- .../pages/testing/mockmvc/htmlunit/why.adoc | 6 +++--- 4 files changed, 18 insertions(+), 16 deletions(-) diff --git a/framework-docs/modules/ROOT/pages/testing/mockmvc/htmlunit/geb.adoc b/framework-docs/modules/ROOT/pages/testing/mockmvc/htmlunit/geb.adoc index d25894625c3..c92d0cc2dde 100644 --- a/framework-docs/modules/ROOT/pages/testing/mockmvc/htmlunit/geb.adoc +++ b/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] ---- diff --git a/framework-docs/modules/ROOT/pages/testing/mockmvc/htmlunit/mah.adoc b/framework-docs/modules/ROOT/pages/testing/mockmvc/htmlunit/mah.adoc index a02af4f66ba..92809e79663 100644 --- a/framework-docs/modules/ROOT/pages/testing/mockmvc/htmlunit/mah.adoc +++ b/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: diff --git a/framework-docs/modules/ROOT/pages/testing/mockmvc/htmlunit/webdriver.adoc b/framework-docs/modules/ROOT/pages/testing/mockmvc/htmlunit/webdriver.adoc index 7f4ac77e8bf..cc4c45c0039 100644 --- a/framework-docs/modules/ROOT/pages/testing/mockmvc/htmlunit/webdriver.adoc +++ b/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 <>, 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 +<>, we can use the Page Object Pattern with +HtmlUnit, but it is much easier with WebDriver. Consider the following `CreateMessagePage` implementation: -- diff --git a/framework-docs/modules/ROOT/pages/testing/mockmvc/htmlunit/why.adoc b/framework-docs/modules/ROOT/pages/testing/mockmvc/htmlunit/why.adoc index 710a310f1d5..9c24ae54bfb 100644 --- a/framework-docs/modules/ROOT/pages/testing/mockmvc/htmlunit/why.adoc +++ b/framework-docs/modules/ROOT/pages/testing/mockmvc/htmlunit/why.adoc @@ -60,7 +60,7 @@ assume our form looks like the following snippet: ---- -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