The Purpose of TestSimple

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.

But yes, TestSimple is designed for doing unit testing in JavaScript. Of all the JavaScript I've seen, I've never seen any decent unit tests. People sometimes 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 coverage in JavaScript tests—if there are any tests at all.

While it's true that JavaScript is nearly always an embedded language (but see also Rhino and SpiderMonkey), that doesn't mean that one doesn't write a lot of JavaScript functions or classes that need testing. It's also important to 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 port because, as I was learning JavaScript, I realized that I didn't want to write much without writing tests. The purpose is to ensure the quality of JavaScript code as it goes through the development process. And the freedom to 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?

Yes. And I expect that, as people write more JavaScript applications, there will be a lot more code that needs testing. However, unlike other JavaScript testing frameworks I've seen (all based on the xUnit framework), my suite doesn't assume that tests will be run in a browser. Ultimatelly, 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 command-line.

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.

Or is the point to Unit test JavaScript functions in the browser in vitro, 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 Browser? (If so, how can a JavaScript arrange to Mock the Model layer?)

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 JavaScript libraries to start mocking whatever other APIs one needs to fully unit test JavaScript code that relies on such libraries.

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 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.

Yes, as more people follow Google's lead, more and more applications will be appearing in JavaScript, and they will require a lot of code. JavaScript already suppports a prototype-based object-orientation scheme, and if JavaScript 2.0 ever becomes a reality (please, please, please, please please!), then we'll have real classes, namespaces, and even import, include and use! Testing will become increasingly important as more organizations come to rely on growing amounts of production JavaScript code.

Backtalk

Gordon McCreight wrote:

TAP-compliant unit tests would also work well for other applications which use an ECMAScript interpreter. Adobe's Flash (ActionScript) and Director (uses SpiderMonkey) are obvious candidates, but even applications like After Effects Professional could benefit from a robust standards-compliant (and FOSS to boot!) unit test framework. You guys (You, Andy, Ingy, chromatic, Autrijus) are my heros. Scary, huh?

Bill N1vux wrote:

Thanks

Thanks, that fills in the blanks. Sounds like it'll be useful, maybe even to those of us who don't write JavaScript.

Bill

Manifesto - Far too many of the POD2HTML docs on CPAN ... and Unix man(1) pages ... assume the readers know why they would use the program/module and just need a detail, not trying to decide if it is even close to the right screw-driver to pound this nail. You always start a project with a purpose, so the documentation should too.