Jay Kimble

[If you aren’t knee deep into Script# or JavaScript this post might not make any sense. If you are into BDD (or TDD) you might want to read further to see some ideas I’m playing with. If you write TDD tools for running tests... please read further... ]

[NOTE (For Joe Only): Joe, yes, this is a "shiny stuff" post; some day it might have a practical use at which point I’ll write a non-alpha geek version of this post which will be a tutorial of how to use this to make your life easier.]

One of the things I’ve been looking for again is a way to create C#-Style (or even Java-Style) attributes on a function in JavaScript. Mind you, I’m the author of such a library, but making it work in Script# is a bit of a pain. To do it would require me writing in Script# something like this (and I’ll give away what I want to do as well):

   1: // NOTE: what follows is something I could do not something that is fully working

   2: // the JS Style Attributes work and that is all

   3:  

   4: [Concern()]

   5: public myClass

   6: {

   7:     public myClass()

   8:     {

   9:         Script.Literal("/*--@Concern()--*/");

  10:     }

  11:  

  12:     [Observation("When adding a person, full name should not be blank")]

  13:     public void When_adding_a_person_full_name_should_not_be_blank()

  14:     {

  15:         Script.Literal("/*--@Concern("When adding a person, full name should not be blank")--*/");

  16:         // Test Code appears here

  17:     }

  18: }

See that Script.Literal in the constructor? That’s required for my JS Attributes Library and for Script#. You see we have to force a comment into Script#, and do it in a manner that the comment ends up in the runtime version (non-debug version) of the code.

So why would I want to use regular attributes as well ("they don’t make their way into the JS code, right?"). Well, since my BDD experimentation is starting to be seen. I’ve started experimenting using Test Driven.Net with Script# assemblies (I took a Bertrand Le Roy’s Simple Test framework for JavaScript and converted it to Script# (I also made a couple enhancements, so I could target alternate consoles... instead of just html). After hooking everything up, I ran the DLL through reflector and sure enough, it decompiled into my exact source code. Next I tried running it with Test Driven.Net personal with no luck... not sure what I need to do to get it running actually, but I bet if I had a Test Attribute that would start sending me in the right direction.

Regardless, I’m not all that interested in regular xUnit style frameworks; I really want BDD. One of the things I started doing was investigating all the BDD style frameworks for .NET. Almost all of them inherit from NUnit, so if I wanted to say port Scott Bellware’s SpecUnit to JavaScript/Script#, then I would need to have an NUnit implementation and a recent one. Recent NUnit implementations all use Attributes which is how we get here. [For the acronym police: BDD stands for Behavior Driven Development... I won’t attempt to define it as I would probably get it wrong, but it’s a variation on Test Driven Development -- TDD... BDD emphasizes testing specs, user stories, use cases, etc.]

BDD with JavaScript
One of the things I’ve been thinking about is how something like Script# DLLs lend themselves for testing. Seriously. If you take an UI behavior approach to components, then you need to isolate the functionality by creating a fake element (or more than one), attach the behavior and then start firing events on the model to make sure that the desired results happen. For instance if I have a draggable element then I want to make sure that the element shows the hand cursor when the mouse passes over the element as well as when the mouse button is down and the mouse is moved does the element’s position changes, etc. I keep thinking that this should be infinitely easier in the DLL as an abstraction then in the actual browser. Of course one needs to test various browsers, but if your math is off for instance, it won’t matter which browser you use.

Why BDD and not TDD? Well, I usually have a list of rules that the UI Behavior should adhere to before I ever write a line of code. This is a perfect fit for a BDD style of test first (and yes, I want to do BDD testing first... I know that’s shocking, but I do want to try it... for how I TRY to build JS components quality is usually a huge factor that BDD would greatly help).