NetKernel News Volume 3 Issue 33

July 27th 2012

What's new this week?

• Repository Updates
• XUnit: Expectations are raised
• ROC Testing Perspective
• Assert Literals
• XSpec the Unexpected
• Exceptional Exceptions
• Holiday Notice

Catch up on last week's news here

Repository Updates

The following updates are available in both the NKEE and NKSE repositories...

• layer0-1.89.1
  • Fixed a potential module unload/load spin in the ModuleManager if lastModified() time on modules.xml or module.xml was in the future. Future modified files are now treated as static and are excluded from dynamic reloading until the system current time catches up with them. Thanks to Brian Sletten for living 8-hours in the past, who discovered this.
• nkse-control-panel-1.24.1
  • Improved exception styling (see below)
• nkse-xunit-1.9.1
  • Added expect/received to assertion model (see below)
  • Added assert literal support
• xml-xspec-1.1.1
  • *NEW* The XSpec xslt unit testing framework (see below)

XUnit: Expectations are raised

The update to nkse-xunit in today's repository updates, provides a requested enhancement to the XUnit framework. The built-in asserts will now report back both the expected and received representation. In the XML format, these values are returned as @assertExpected and @assertReceived attributes on the assert.

For example, here's a failing assert on a test that is expected to have cost a maximum of 100 but actually cost 66813...

The HTML view of the asserts also now displays these expectation values...

SINKing Expectations

When writing a custom assert, if the assert does not pass, you now have the option to SINK expected and received values to the resources...

 active:assert/Expected
 active:assert/Received

The representations you SINK must be transreptable to java.lang.String since they will be incorporated into the attribute value of the assert result.

ROC Testing Perspective

Its important to understand that the XUnit test framework is not a "source code" unit-testing tool. Its intent is to test the ROC domain, which as you know is a two-phase computational model. First resolution and then execution of requests.

By allowing declarative test requests to be made the XUnit framework enables the address space (and its dynamic resolution relations) to be probed. This is important both for initial development where you are adding new constructs to the ROC space. But also for regression testing - especially when spaces and spacial architectures may be dynamically composed by, for example, using dynamic imports.

The second role of the XUnit engine is to execute the request in the resolved endpoint. Which is actually where things gets a little subtle - especially for the interpretation and reporting of expects and received state.

Clearly, to be a valid test, it is very important that the XUnit test request does not cause Heisenberg effects on the tested system. For example it would be completely wrong for the test engine to trigger type transreption, by for example always saying the received representation should be a String (so that it can be reported in the assertReceived attribute). The Unit test engine cannot do anything to influence the tested service in order to satisfy its own requirements. Otherwise you're not testing the service, you're testing the "unit-test-engine contextual behaviour of the service" which is subtly different thing.

So the unit test engine never imposes Heisenberg effects on the tested space through its own context. But in order to preserve this essential constraint we had to come up with the sneaky trick so that custom asserts can report back expect/received state. We do this by borrowing the HTTPBridge superstack pattern. We inject the active:assert/Expected and active:assert/Received resources into the superstack of each custom assert request.

When the custom assert completes and returns a boolean false result, the unit test engine checks for the EXISTance and, if present, SOURCEs active:assert/Expected and active:assert/Received and uses these in the testing report.

But just to be clear, at no point does the XUnit framework itself do anything but sequence requests. It never ever touches representation state.

Assert Literals

An additional enhancement we added to XUnit is that asserts may now use the declarative request's literal syntax.

For example...

Literals support several standard types but may also invoke new instances of Java classes. The referenced class must be accessable in the classpath of the module that defines the unit tests.

For example here is an assert with a literal URI object...

XSpec the Unexpected

While on the subject of testing. We have integrated the XSpec unit testing suite as a set of services - it is available in the repos as the package xml-xspec.

XSpec is a tool for testing XSLT stylesheets. For details and examples of the declarative XSpec testing language see the XSpec home...

http://code.google.com/p/xspec/

We've modeled XSpec as a domain specific language runtime. So you can call active:xspecXML or active:xspecHTML as regular services (even integrated into nCoDE). In addition, you can drive XSpec tests from XUnit and we've created a custom assert for XUnit that asserts the success (or failure) of the set of XSpec tests.

The best way to get an idea of what's possible is to try out our own xspec unit tests...

urn.test.org.netkernel.xml.xspec-trunk.jar

Exceptional Exceptions

Finally, one more enhancement in today's repo updates. Based upon constructive user feedback we have given a make-over to the HTML styling of exception resources.

We've tried to declutter the display, hide the Java stacktrace unless you care about it (to make things less scary) and also we've made it much clearer that the exception is a linked-data resource and it provides live links into the Space Explorer to show you the spacial context of the exception (or any of the request frames).

Here's a taster of a couple of request frames without the Java stacktraces expanded...

You'll find that we also added a link at the very top of the page to take you directly to the last frame (which is usually the causal exception).

To try it for yourself, install the nkse-control-panel update in Apposite then try this link...

http://localhost:1060/this/is/not/here

Holiday Notice

Its the summer and for the next 2-3 weeks members of the team will be suffering enforced time with their families. We've arranged that we will always have support cover on hand to respond to emergency incidents. But please be aware our day-to-day advice and assistance may be a little less responsive.

If you have an emergency, please send email to: support [a.t.] 1060research [d.o.t.] com - we'll never be far from email or phone if you really need us.

As a reward you won't have to suffer any newsletters for a couple of weeks.