In response to my TestSimple 0.03 announcement, Bill N1VUX asked a number of
important questions about TestSimple’s purpose. Since this is just an alpha
release and I’m still making my way though the port, I haven’t created a project
page or started to promote it much, yet. Once I get the harness part written and
feel like it’s stable and working well, I’ll likely start to promote it as
widely as possible.
write a few integration tests to test them in browsers, but don’t write many
tests that would ensure that their JS code runs where they need it to run and
that would give them the freedom to refactor. There is generally very little
also Rhino and SpiderMonkey), that doesn’t mean that one doesn’t write a lot
have a lot of tests you can run in various browsers (just as you can run tests
of a Perl module on various OSs and various versions of Perl). I started the
write much without writing tests. The purpose is to ensure the quality of
refactor that tests offer is very important for my personal development style.
So, to answer N1VUX’s questions:
Is the point to integration test the whole distributed front-ends of
applications from the (EcmaScript compliant) browser?
frameworks I’ve seen (all based on the xUnit framework), my suite doesn’t assume
that tests will be run in a browser. Ultimately, I’d like to be able to automate
tests outside of browsers—or by scripting browsers. But in the meantime, it will
produce TAP-compliant output in the browser, and I plan on implementing a
harness that will run all of your test scripts in a single browser window and
output the results, just like Test::Harness does for Perl modules on the
Or to unit test the client-side java-script as an entity, mocking the server??
Yes, I would like to be able to do that eventually. I will likely mock the
server by mocking XMLHttpRequest and Microsoft.XMLHTTP to return XML strings
that can be used for testing. Stuff like that.
mocking everything outside the current function?
If need be, yes. The point is that you have the freedom to do it the way that
makes sense to your particular project. The testing framework itself doesn’t
care where it’s run or how.
Or is this for Unit Testing of the Presentation Layer on the server from the
Probably not, but again, it depends on the model of your application. I’ve tried
to make no assumptions, just provide you with the tools to easily test your
application. I hope and expect that others will start creating the appropriate
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?
That was my initial impetus, yes.
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
that fancy? *shudder* no wonder pages don’t work between browser versions.)
I hope I don’t need to do that.
Yes, as more people follow Google’s lead, more and more applications will be
ever becomes a reality (please, please, please, please please!), then we’ll
have real classes, namespaces, and even
Testing will become increasingly important as more organizations come to rely on
Looking for the comments? Try the old layout.