<commit_before>


A good way to start getting confident with Wicket unit testing support is looking at the test case class _TestHomePage_ that is automatically generated by Maven when we use Wicket archetype to create a new project:

image::../img/mvn-wicket-archetype.png[]

Here is the content of TestHomePage:

[source,java]
----
public class TestHomePage{
	private WicketTester tester;

	@Before
	public void setUp(){
		tester = new WicketTester(new WicketApplication());
	}
	@Test
	public void homepageRendersSuccessfully(){
		//start and render the test page
		tester.startPage(HomePage.class);
		//assert rendered page class
		tester.assertRenderedPage(HomePage.class);
	}
}
----

The central class in a Wicket testing is _org.apache.wicket.util.tester.WicketTester_. This utility class provides a set of methods to render a component, click links, check if page contains a given component or a feedback message, and so on.

The basic test case shipped with _TestHomePage_ illustrates how _WicketTester_ is typically instantiated (inside method _setUp()_). In order to test our components, WicketTester needs to use an instance of _WebApplication_. Usually, we will use our application class as _WebApplication_, but we can also decide to build WicketTester invoking its no-argument constructor and letting it automatically build a mock web application (an instance of class _org.apache.wicket.mock.MockApplication_).

The code from _TestHomePage_ introduces two basic methods to test our pages. The first is method _startPage_ that renders a new instance of the given page class and sets it as current rendered page for WicketTester. The second method is assertRenderedPage which checks if the current rendered page is an instance of the given class. In this way if TestHomePage succeeds we are sure that page HomePage has been rendered without any problem. The last rendered page can be retrieved with method _getLastRenderedPage_.

That's only a taste of what _WicketTester_ can do. In the next paragraphs we will see how it can be used to test every element that composes a Wicket page (links, models, behaviors, etc...).

=== Testing links

A click on a Wicket link can be simulated with method _clickLink_ which takes in input the link component or the page-relative path to it.

To see an example of usage of clickLink, let's consider again project _LifeCycleStagesRevisited_. As we know from chapter 5 the home page of the project alternately displays two different labels (“First label” and “Second label”), swapping between them each time button "reload" is clicked. The code from its test case checks that label has actually changed after button "reload" has been pressed:

[source,java]
----
//...
@Test
public void switchLabelTest(){
	//start and render the test page
	tester.startPage(HomePage.class);
	//assert rendered page class
	tester.assertRenderedPage(HomePage.class);
	//assert rendered label
	tester.assertLabel("label", "First label");
	//simulate a click on "reload" button
	tester.clickLink("reload");
	//assert rendered label
	tester.assertLabel("label", "Second label");	
}
//...
----

In the code above we have used _clickLink_ to click on the "reload" button and force page to be rendered again. In addition, we have used also method _assertLabel_ that checks if a given label contains the expected text.

By default _clickLink_ assumes that AJAX is enabled on client side. To switch AJAX off we can use another version of this method that takes in input the path to the link component and a boolean flag that indicates if AJAX must be enabled (true) or not (false). 

[source,java]
----
//...
//simulate a click on a button without AJAX support
tester.clickLink("reload", false);
//...
----

=== Testing component status

WicketTester provides also a set of methods to test the states of a component. They are:

* *assertEnabled(String path)/assertDisabled(String path)*: they test if a component is enabled or not.
* *assertVisible(String path)/assertInvisible(String path)*: they test component visibility.
* *assertRequired(String path)*: checks if a form component is required.

In the test case from project _CustomDatepickerAjax_ we used _assertEnabled_/_assertDisabled_ to check if button "update" really disables our datepicker:  

[source,java]
----
//...
@Test
public void testDisableDatePickerWithButton(){
	//start and render the test page
	tester.startPage(HomePage.class);
	//assert that datepicker is enabled
	tester.assertEnabled("form:datepicker");
	//click on update button to disable datepicker
	tester.clickLink("update");
	//assert that datepicker is disabled
	tester.assertDisabled("form:datepicker");		
}
//...
----

=== Testing components in isolation

Method _startComponent(Component)_ can be used to test a component in isolation without having to create a container page for this purpose. The target component is rendered and both its methods _onInitialize()_ and _onBeforeRender()_ are executed. In the test case from project _CustomFormComponentPanel_ we used this method to check if our custom form component correctly renders its internal label:

[source,java]
----
//...
@Test
public void testCustomPanelContainsLabel(){
	TemperatureDegreeField field = new TemperatureDegreeField("field", Model.of(0.00));
	//Use standard JUnit class Assert	
	Assert.assertNull(field.get("mesuramentUnit"));		
	tester.startComponent(field);		
	Assert.assertNotNull(field.get("mesuramentUnit"));
}
//...
----

If test requires a page we can use _startComponentInPage(Component)_ which automatically generates a page for our component.

=== Testing the response

_WicketTester_ allows us to access to the last response generated during testing with method _getLastResponse()_. The returned value is an instance of class MockHttpServletResponse that provides helper methods to extract information from mocked request.

In the test case from project _CustomResourceMounting_ we extract the text contained in the last response with method _getDocument_ and we check if it is equal to the RSS feed used for the test: <commit_msg>Remove usage of deprecated method from test example<commit_after>


A good way to start getting confident with Wicket unit testing support is looking at the test case class _TestHomePage_ that is automatically generated by Maven when we use Wicket archetype to create a new project:

image::../img/mvn-wicket-archetype.png[]

Here is the content of TestHomePage:

[source,java]
----
public class TestHomePage{
	private WicketTester tester;

	@Before
	public void setUp(){
		tester = new WicketTester(new WicketApplication());
	}
	@Test
	public void homepageRendersSuccessfully(){
		//start and render the test page
		tester.startPage(HomePage.class);
		//assert rendered page class
		tester.assertRenderedPage(HomePage.class);
	}
}
----

The central class in a Wicket testing is _org.apache.wicket.util.tester.WicketTester_. This utility class provides a set of methods to render a component, click links, check if page contains a given component or a feedback message, and so on.

The basic test case shipped with _TestHomePage_ illustrates how _WicketTester_ is typically instantiated (inside method _setUp()_). In order to test our components, WicketTester needs to use an instance of _WebApplication_. Usually, we will use our application class as _WebApplication_, but we can also decide to build WicketTester invoking its no-argument constructor and letting it automatically build a mock web application (an instance of class _org.apache.wicket.mock.MockApplication_).

The code from _TestHomePage_ introduces two basic methods to test our pages. The first is method _startPage_ that renders a new instance of the given page class and sets it as current rendered page for WicketTester. The second method is assertRenderedPage which checks if the current rendered page is an instance of the given class. In this way if TestHomePage succeeds we are sure that page HomePage has been rendered without any problem. The last rendered page can be retrieved with method _getLastRenderedPage_.

That's only a taste of what _WicketTester_ can do. In the next paragraphs we will see how it can be used to test every element that composes a Wicket page (links, models, behaviors, etc...).

=== Testing links

A click on a Wicket link can be simulated with method _clickLink_ which takes in input the link component or the page-relative path to it.

To see an example of usage of clickLink, let's consider again project _LifeCycleStagesRevisited_. As we know from chapter 5 the home page of the project alternately displays two different labels (“First label” and “Second label”), swapping between them each time button "reload" is clicked. The code from its test case checks that label has actually changed after button "reload" has been pressed:

[source,java]
----
//...
@Test
public void switchLabelTest(){
	//start and render the test page
	tester.startPage(HomePage.class);
	//assert rendered page class
	tester.assertRenderedPage(HomePage.class);
	//assert rendered label
	tester.assertLabel("label", "First label");
	//simulate a click on "reload" button
	tester.clickLink("reload");
	//assert rendered label
	tester.assertLabel("label", "Second label");	
}
//...
----

In the code above we have used _clickLink_ to click on the "reload" button and force page to be rendered again. In addition, we have used also method _assertLabel_ that checks if a given label contains the expected text.

By default _clickLink_ assumes that AJAX is enabled on client side. To switch AJAX off we can use another version of this method that takes in input the path to the link component and a boolean flag that indicates if AJAX must be enabled (true) or not (false). 

[source,java]
----
//...
//simulate a click on a button without AJAX support
tester.clickLink("reload", false);
//...
----

=== Testing component status

WicketTester provides also a set of methods to test the states of a component. They are:

* *assertEnabled(String path)/assertDisabled(String path)*: they test if a component is enabled or not.
* *assertVisible(String path)/assertInvisible(String path)*: they test component visibility.
* *assertRequired(String path)*: checks if a form component is required.

In the test case from project _CustomDatepickerAjax_ we used _assertEnabled_/_assertDisabled_ to check if button "update" really disables our datepicker:  

[source,java]
----
//...
@Test
public void testDisableDatePickerWithButton(){
	//start and render the test page
	tester.startPage(HomePage.class);
	//assert that datepicker is enabled
	tester.assertEnabled("form:datepicker");
	//click on update button to disable datepicker
	tester.clickLink("update");
	//assert that datepicker is disabled
	tester.assertDisabled("form:datepicker");		
}
//...
----

=== Testing components in isolation

Method _startComponentInPage(Component)_ can be used to test a component in isolation. The target component is rendered in an automatically generated page and both _onInitialize()_ and _onBeforeRender()_ are executed. In the test case from project _CustomFormComponentPanel_ we used this method to check if our custom form component correctly renders its internal label:

[source,java]
----
//...
@Test
public void testCustomPanelContainsLabel(){
	TemperatureDegreeField field = new TemperatureDegreeField("field", Model.of(0.00));
	//Use standard JUnit class Assert
	Assert.assertNull(field.get("mesuramentUnit"));
	tester.startComponentInPage(field);
	Assert.assertNotNull(field.get("mesuramentUnit"));
}
//...
----

=== Testing the response

_WicketTester_ allows us to access to the last response generated during testing with method _getLastResponse()_. The returned value is an instance of class MockHttpServletResponse that provides helper methods to extract information from mocked request.

In the test case from project _CustomResourceMounting_ we extract the text contained in the last response with method _getDocument_ and we check if it is equal to the RSS feed used for the test: 
{'fraction_non_alphanumeric': 0.06887098114148044, 'fraction_numerical': 0.000664617429592091, 'mean_word_length': 4.638407494145199, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '6958457', 'n_tokens_mistral': 3143, 'n_tokens_neox': 3057, 'n_words': 1551}