Canoo Webtest WebTest Canoo

Extension Step forceHiddenInputField


Sets the value of a hidden input field. An example usage would be for a hidden input field that would normally be set by some unsupported JavaScript.

This step provides a mechanism to alter the value of a hidden input field. Hidden input fields are often used within forms to help with state management of a web application. They are often set using JavaScript and because not all features of JavaScript are supported by Canoo WebTest, it can sometimes be useful to mimic what the JavaScript would do with a manual step.

If you have a very sophisticated web application that makes use of a lot of hidden input fields for your state management, this step can assist you in partitioning your tests into their functional and "unit" aspects. Firstly, you write "unit" tests where you manipulate your application in various ways and check that the hidden fields are set appropriately. These don't require invoking the server application so they run fast. Then you run some functional tests which check that for a given set of values of the hidden fields, your application performs as expected.


Required? yes
The value to use when setting the field of interest.
Required? no
The description of this test step.
Required? no, default is the first field found that matches criteria
The index of the field of interest (starting at 0) if more than one field matches criteria. Ignored if htmlId or xpath is used.
Required? yes/no
The text of the label field associated with the input field of interest. One of forLabel, htmlId, name, or xpath is required.
Required? no, default is the last form selected using 'selectForm', otherwise searches all forms
The name of the form containing the field of interest. Ignored if htmlId is used.
Required? yes/no
The id of the input field of interest. One of forLabel, htmlId, name, or xpath is required.
Required? yes/no
The name of the input field of interest. One of forLabel, htmlId, name, or xpath is required.
Required? no
A shorthand: save='prefixName' is the same as savePrefix='prefixName' saveResponse='true'.
Required? no, default is the 'savePrefix' parameter as specified in <config>.
A name prefix can be specified for making a permanent copy of received responses. A unique number and the file extension (depending on the MIME-Type) will be appended. The resultpath attribute of the <config> element is used for determining the location of the saved result.
Required? no
Whether to make a permanent copy of received responses. Overrides the default value set in the <config> element.
Required? yes/no
The xpath of the input field of interest. One of forLabel, htmlId, name, or xpath is required.

Inline Text

The inline text is all the text between the start tag ( <forceHiddenInputField> ) and the end tag ( </forceHiddenInputField> ), including blanks, tabs or newlines. Using a pair of start/end tags ( <forceHiddenInputField> </forceHiddenInputField> ) has not the same behavior than the seemingly equivalent empty element tag ( <forceHiddenInputField/> )! See this issue for an example.

Required? no
An alternative to the attribute value for e.g. large TextAreas.


Consider the following HTML form:

<title>Hidden Field Test Page</title>
<script type="text/javascript">
function setField(id, value) {
  var field = document.getElementById(id);
  field.value = value;
  return false;
// -->


<form method="GETaction="dummy.html" >
    Enter Value (then click outside box): <input name="field1onchange="setField('real', 'xxx')"><br>
    Enter Value (auto checks): <input name="field2onkeyup="setField('real', 'yyy')"><br>
    <input type="hiddenid="realname="hiddenFieldvalue="zzz" />
    <input type="submitvalue="Click Mename="button" >


This page contains some JavaScript functionality which sets a hidden field. We would like to use the <forceHiddenInputField> step to check that the hidden field is being set correctly. When the form is first loaded, the hidden field should be set to 'zzz'. We can then place some content into 'field1'. We can then check that the hidden field was successfully changed to 'xxx'. Here is an example test script:

hiddenInputField Example1
<webtest name="forceHiddenInputField: Show working javascript example that sets hidden field">
    <config ...>
        <invoke ...>
        <verifytitle description="check we are on the test pagetext="Hidden Field Test Page" />
        <verifyXPath description="check original value of hidden field"
            xpath="//form/input[@id='real']/@valuetext="zzz" />
        <setInputField description="anything here should change hidden fieldname="field1value="dummy" />
        <verifyXPath description="check updated value of hidden field"
            xpath="//form/input[@id='real']/@valuetext="xxx" />

We can try to do the same thing for 'field2', however because the onkeyup JavaScript event is not supported, the hidden field remains unchanged. We can then use the <forceHiddenInputField> to force the hidden field change to 'yyy'. Here is the script code:

hiddenInputField Example2
<webtest name="forceHiddenInputField: Show usage of forceHiddenInputField step for non-working javascript">
    <config ...>
        <invoke ...>
        <verifytitle description="check we are on the test pagetext="Hidden Field Test Page" />
        <verifyXPath description="check original value of hidden field"
            xpath="//form/input[@id='real']/@valuetext="zzz" />
        <setInputField description="javascript limitations inhibit change to hidden field"
            name="field2value="dummy" />
        <verifyXPath description="check value of hidden field remains the same"
            xpath="//form/input[@id='real']/@valuetext="zzz" />
        <forceHiddenInputField name="hiddenFieldvalue="yyy"/>
        <verifyXPath description="check updated value of hidden field"
            xpath="//form/input[@id='real']/@valuetext="yyy" />
        <-- could now submit form to backend server expecting modified value -->

See also: the storeXPath and verifyXPath steps which can be used to read/verify hidden fields.


Latest build: development
Posted: 19-Jul-2016 17:36

WebTest 3.0 released, featuring upgrades to Java 5, Groovy 1.6, and HtmlUnit 2.4.
The release includes support for maven integration, IDE-integration like for unit tests, capturing of background JavaScript errors, new steps for mouseOver and mouseOut events, better parallel execution of tests and - as usual - lots of handling improvements.
Posted: 5 March 2009

WebTest @ JavaOne
Dierk König presented "Functional testing of web applications: scaling with Java" on Wed May 7, 13:30 at JavaOne 2008 in the Tools and Scripting Languages track.
Posted: 8 May 2008

New WebTest screencast available:
Data Driven WebTest
Posted: 13 November 2007

First WebTest screencast available:
Creating a first Webtest Project

Extend WebTest with Groovy! Groovy in Action is available in every good bookstore.
Groovy in Action
Posted: 29 January 2007