All the Perl that's Practical to Extract and Report

JavaScript TestSimple 0.03 Released

Theory on 2005-04-29T19:09:20

I'm pleased to announce the third alpha release of TestSimple, the port of Test::Builder, Test::Simple, and Test::More to JavaScript. You can download it here. This release has the following changes:

  • Removed trailing commas from 3 arrays, since IE6/Win doesn't like them. And now everything works in IE. Thanks to Marshall Roch for tracking down and nailing this problem.
  • isNum() and isntNum() in TestBuilder.js now properly convert values to numbers using the global Number() function.
  • CurrentTest is now properly initialized to 0 when creating a new TestBuilder object.
  • Values passed to like() and unlike() that are not strings now always fail to match the regular expression.
  • plan() now outputs better error messages.
  • isDeeply() now works better with circular and repeating references.
  • diag() is now smarter about converting objects to strings before outputting them.
  • Changed isEq() and isntEq() to use simple equivalence checks (== and !=, respectively) instead of stringified comparisons, as the equivalence checks are more generally useful. Use cmpOk(got, "eq", expect) to explicitly compare stringified versions of values.
  • TestBuilder.create() now properly returns a new TestBuilder object instead of the singleton.
  • The useNumbers(), noHeader(), and noEnding() accessors will now properly assign a non-null value passed to them.
  • The arrays returned from summary() and details() now have the appropriate structures.
  • diag() now always properly adds a # character after newlines.
  • Added output(), failureOutput(), todoOutput(), warnOutput(), and endOutput() to TestBuilder to set up function reference to which to send output for various purposes. The first three each default to document.write, while warnOutput() defaults to window.alert and endOutout() defaults to the appendData function of a text element inside an element with the ID test or, failing that, window.write.
  • todo() and todoSkip() now properly add # after all newlines in their messages.
  • Fixed line ending escapes in diagnostics to be platform-independent. Bug reported by Marshall Roch.
  • Ported about a third of the tests from Test::Simple (which is how I caught most of the above issues). The remaining test from Test::Simple will be ported for the next release.

Many thanks to Marshall Roch for help debugging issues in IE.

Now, there is one outstanding issue I'd like to address before I would consider this production ready (aside from porting all the remaining tests from Test::Simple): how to harness the output. Harnessing breaks down into a number of issues:

How to run all tests in a single window. I might be able to write a build script that builds a single HTML file that includes all the other HTML files in iframes or some such. But then will each run in its own space without stomping on the others? And how would the harness pull in the results of each? It might be able to go into each of its children and grab the resultsfrom the TestBuilder objects...

More Feedback/advice/insults welcome!

Purpose?

n1vux on 2005-04-30T01:16:19

This looks potentially useful, but I'm unsure for what.

Since Perl Test::Simple/Test::Builder is generally considered a Unit Testing framework (although it can be (ab)used as a Integration-Regression engine as well), and JavaScript (or ECMA Script) runs in a Browser that is usually deeply connected, I'm missing a contextual leap here.

I could really use a link to a web page describing the purpose and scope of the TestSimple JavaScript port. All the posts on Just A Theory and here are "Implementor's Doc", change-lists of what's implemented/fixed from your point of view. If there's a "Project Homepage", it's not linked.

  • Is the point to integration test the whole distributed front-ends of applications from the (EcmaScript compliant) browser?
  • Or to unit test the client-side java-script as an entity, mocking the server??
  • Or is the point to Unit test JavaScript functions in the browser in vitro, mocking everything outside the current function?
  • Or is this for Unit Testing of the Presentation Layer on the server from the Brtowser? (If so, how can a JavaScript arrange to Mock the Model layer?)
  • Or is it more likely for driving Integration Testing from the browser with the scripting simplicity we've come to love, without resorting to OLE-stuffing the browser from Perl?
Digging into the TAR file (which I normally wouldn't do before peaking at the web copy of the POD2HTML's) I think I understand it's for unit-testing JavaScript classes, which I hadn't even considered. (JavaScript has classes that fancy? *shudder* no wonder pages don't work between browser versions.) I hope I don't need to do that.

How much of the other items above could I do with it, if any?

Re:Purpose?

Theory on 2005-05-03T01:04:26

Bill,

Apologies for the delayed reply. I've been busy with other things for the last few days.

I thought that your questions were important enough that I wrote a separate post to address them.

—Theory

Re:Purpose?

n1vux on 2005-05-05T01:03:38

Thanks, I'll check it out.