The CODE Framework Service Test Harness is a tool that allows to quickly test services of various kinds. To use the Test Harness, services have to be hosted in the Development Test Host (for more information on using the Development Test Host and developing
services with CODE Framework in general, see http://www.codemag.com/Article/1203061).
In the Service Test Host, services use color-coded icons to make it easy and intuitive which protocol and standard is used to host a service. Blue is used for REST services (both, for the common JSON as well as XML formatted REST services). Orange is used for
SOAP services (basic and WS). Green is used for binary TCP/IP services.
You can double-click a service in the development host, the Test Harness launches. The title of the Test Harness window shows the name of the implemented contract as well as the protocol and standard used for that particular service. Also, the entire window
is color coded, just like the hosted services in the host window, making it easy to differentiate between different versions of the same service. (It is possible to launch multiple Test Harnesses for the same service based on different hosting versions. The
color-coding makes it very easy to differentiate between these versions).
The Test Harness provides a list of Operations (Methods) the service exposes. Select one of those to see more details on the operation, including the input and output messages ("parameters") for those operations. Using the Test Harness, developers
can hand-craft input messages to be sent to the service. These messages can (and should) be complex objects with various types of members, ranging from simple things such as strings or boolean values, to complex members, such as binary fields or collections
of sub-objects. The harness supports populating all these in a convenient tree UI.
Note that some fields allow for special features. For instance, GUID fields allow for the creation of an empty or a new random GUID. Collections allow adding sub-items. Binary fields can be populated by loading files. And so forth.
Once the developer has crafted the desired input message/parameter, the operation can be invoked ("called") by hitting the Invoke button. (Note: It is also possible to hit CTRL-I or CTRL-ENTER to invoke the operation). The Test Harness invokes the
operation using standard infrastructure. For instance, if a service is hosted as a WCF TCP/IP service, the Harness uses WCF's TCP/IP infrastructure in a free-threaded fashion to invoke the service. If the service is hosted using REST/JSON, a WebClient-based
call is made. And so forth.
The result is then displayed in the result Message Visualizer.
There are a few extra things that should be mentioned about editing input messages:
In complex services, input messages can also be complex. During development and testing, it can be cumbersome having to re-enter the same message over and over. The Test Harness acknowledges and embraces this by letting developers save messages for future use.
The simplest way to do so is by hitting the "Quick Save" button (or hitting CTRL-S) which saves the current message away to disk. Later, the same message can be loaded again using the "Quick Load" button (or CTRL-L), which retrieves and
loads that message again. Similarly, messages can be explicitly saved and loaded using the Save and Load buttons, which lead to explicitly names messages (files).
Note that messages are saved on the hard-drive in JSON format. By default, they are put into a sub-folder ("Contracts") of the folder the test host runs in (messages for each contract and operation are put into further sub-folders). This way, the
messages become part of the folder structure of the solution. This can been seen as "polluting the folder structure", but that's fine, since the development host project is only a development artifact anyway that is not used for runtime deployment.
Also, this leaves the option for the developer to check these files into the source control system if a sharing of standard messages for test purposes is desired.
Also note that the JSON format makes this operation somewhat fault-tolerant. It is easily possible to add more fields to the contract or change various other details, without having to abandon previous versions. This is very convenient during development.
A further point of interest is that messages can be edited in various ways. The tree UI is the default, but one can also switch into JSON and XML representations of the same message. This is not just a read-only version (although it is convenient to always
"Invoke" to call the service with the input message based on XML and JSON. All services can be modified in any standard. For instance, a binary TCP/IP service can have its input message edited in JSON. A JSON/REST service can have its input message
edited in XML. And so on. The input editor is simply a UI to edit an in-memory message that is then passed on to the service appropriately, independent of the version used to edit it.
Another details that is worth noting is that in addition to the name of the operation and the utilized contracts, this window also shows the URI used to access the service. This includes the protocol (such as HTTP or net.tcp) as well as the HTTP Verb for
REST services (such as GET, PUT, POST,…). Furthermore, in REST scenarios, the URL dynamically updates if needed. For instance, a “SearchCustomer” service called over REST (GET Verb) may require passing the search parameter as part of the