Now for some web specific whys/values I do the in-memory acceptance testing…

• Semantic Html is my golden hammer
• Progressive enhancement is my swiss army knife
• I love JavaScript but try to never write any but if i must I make sure it’s generic. I try very hard to make sure no else writes any either and if they do I just refactor it till it deletes itself.
• I love AHAH and barely tolerate AJAX / JSON
• REST is my natural state not something I read about

All of these forces / values / beliefs drive me to solve the problem of web testing in a very different approach from most people. It is about an alternative holistic approach to web architecture, testing and productivity.

(Previously on TWSDEV)

As the “crazy” guy behind the in-memory / out-of-container acceptance testing on a number of java/.net projects, I think it’s important I explain to people the “Why” and the forces / constraints I am trying to balance. But first I want to quickly lay down my beliefs and values:

• I believe in testing as much as possible (UI included)
• I believe tests must add more value than they cost (Measure it!)
• I value tests that are fast and are resilient to change more than tests that take a long time to run and are brittle.
• When refactoring a feature I value acceptances tests and integration test over unit tests.
• When designing/exploring a new interface / object interaction I value unit tests over acceptance tests to help guide me.
• I believe that QA’s are so much better at finding bugs than DEVs but worse at writing code / abstractions

Wow Dyson have done it again: http://www.dyson.co.uk/technology/airmultiplier.asp

Interestingly they talk about the fact they had to do “Hundreds of iterative tests” to get the design right:

http://www.dyson.co.uk/insidedyson/default.asp#Air_Mult_Tech_Dev

If you have met me or worked with me in the last 15 years or so, you will know that I am pretty mad about the web as a platform, HTTP as a protocol and HTML as a state engine. Add to this the last 6 years or so practising agile techniques while building highly scalable websites and you tend to find that I have fairly unusual views in the field about how to build and architect web applications.

So I noticed an issue with Google Chromium and it not updating the cached entry with new headers on a HTTP 304 response. So I logged the issue last weekend and bang! 6 days later the issue is resolved and I have a new version of the browser on my desktop.

Not only was the process super fast but I watched the fix being discussed then applied. I looked at the code change and the unit tests being updated all as it happened. Needless to same I am very impressed.

So after rediscovering the distraction free editors to write reports, it seemed mad not to use the same environment to update my blog. I really like the fact that the editor only supports plain text and didn’t want to reduce the readability of the plain text by having lots of unneeded markup all over the place.

What I needed was a simple tool to convert my semi structured text into html and then I could just upload that to my blog. Ideally the tool would be a command line tool so I could easily automate the two steps.

So many moons ago I was reading about a fullscreen editor for Mac called WriteRoom. The basic premise is that it is a very limited editor that actively aims to block out all distractions from writing. It achieves this by:

• Running fullscreen (so no desktop distractions)
• Supporting plain text only (so no styling distractions)
• No toolbar
• No menubar
• No statusbar
• A few simple shortcuts to do what you need

Anyway I have been running Ubuntu for a number of years, and had often ran Nano fullscreen in a Gnome Terminal but was curious what might now be available. So a few moments googling and this was the list:

One of the pain points we see on web projects is the divide between client side and back end development. This pain might show itself in a number of ways:

• Small changes in the HTML cause lots of tests to fail
• Small changes to visual layout require large changes to the HTML which then causes the above
• Developers say the work is done but it can’t be signed off as it looks terrible or doesn’t work in certain browsers
• CSS or QAs want developer to add ID attributes to lots of elements so they can target them more easily

Now ideally all your developers should be poly skilled and understand javascript / CSS / HTML just as well as they understand java / C# / ruby but often the reality is not quite so rosy.
So if we are working in a world where we don’t have the ideal but still need to get the job done what can we do to reduce the pain?

UPDATE: Jim pointed out that you can access the field via reflecting over the delegate.  (See comment) Damn this is a bit like how java does anonymous access to private fields of the parent class. I wonder if you could use this for some nasty security violations as people tend to think local variables are safe from reflection.

After the crazy !@$%  with JavaScript yesterday I said to Christian, I bet we can do this with C# lambda. So the challenge was set….

So I was chatting with Christian Blunden about JavaScript, and he asked if it was possible to have private fields in JavaScript.

Now the language doesn’t have a key word but I knew that you could use function scoping to achieve the same affect as I had seen the same thing done using the E programming language.

So after 5 minutes here is what we came up with:

function Purse(money) {
	this.getMoney = function() {
		return money;
	}
	this.setMoney = function(newMoney) {
		money = newMoney;
	}
}

This will create a truely private field that can only be accessed via the methods.