Ugh……’Fun with JavaScript – Part 0′

I was working on using javascript as a system scripting tool using wscript.  Here’s a quick summary of highlights:

1. Worked on implementing an include mechanism to include other .js files from inside the js script (no real support for it).  The implemention was a little on the ugly side, but I like it overall.  Currently includes are defined in include.js, but am considering moving this to an XML config file.

2. Played with WScript.Network.  Just messed with the capabilities in general and went ahead and threw the current userid into the scripts.

3. Investigated some of the OO features of javascript and started a couple of ‘class libraries’.  These are just reusable .js files that I treat as libraries and call in the includes.  Messed with inheritance…which is a little strange in javascript.

4. Used the hell out of anonymous methods.

5. Started mock libraries for web-based objects (such as window, document, etc).

6. Began work on a simple test framework – Was going to use jsUnit, but saw that it required the tests to run in the browser…I didn’t want that as my scripts are made to run in the command shell…initially provided supported Assert.Equals because that’s all I needed

7. Worked on Hashtable class (instead of using Array) – Array didn’t do it for me besause it manages the count in a strange way.  For instance, you can add new items using the key (like session variables) like so.  myArray[“keyVal”] = valueString;  At that point you can accces valueString usinf the keyVal or you can say something like for(key in myArray(){ doSomething(myArray[key]);}.  You’ve entered data and can take it back out…wich is great…except for the fact that myArray.length still evaluated to 0;  I want to look at this more.  Gotta firgure out how to do the key iterator.

8. Skimmed the surface with BDD support – When writing a test with my half-assed test framework you define an object as type test then override the Run() method on the test and then add it to the TestSuite object.  Once all tests are added the user calls. testSuite.Run() and all the suites tests fire off.  Assertion object has been replaced with Context and the asserts read something like this now: Context(“Hashtable is instantiated”).ShouldBeEqual(expected, actual).  As you see, I’ve only made a first pass but I want to continue to tweak it based on what I learn from rspec.  I was pleased to find that I could use a javascript class as a method (Context is a class but you can call a class as a method if you don’t use the new operator and you aren’t trying to assign the return value to anything.

9. Took brief look at log4js – It’s pretty lightweight and I may try to port core concepts and a console appender, rolling file appender and possibly a system event appender.  log4js itself is geared toward web use only (like jsUnit) so wasn’t useful.

10. Planned on writing an XML config file (mentioned above) to facilitate include paths for .js files.  Right now include expected the filed to be either in the same directory or mapped through a PATH value.

11. Added a puts() method to common.js, but would like to find a way to easily swap out the tarket resource (like puts to files instead of the console.

So, that it in a nutshell.  I think that we might be able to use the command shell approach to run BDD-type tests agains individual .js files with needing to invoke the browser. 

Good morning to you all