Janko in a Jar

Testing.. it’s the thing you really have to do a lot, well, and on each itteration — if you are serrious at least. If you have a more algoritmic code, a code that produces something out of something Unit tests are great. But most web-apps are not like that. Web apps are like a big muddy balls of state that you keep changing with your little pokes (POSTs).

I need to do a lot testing for my Site Assistant web-app right now and it’s a dull thing, so I started making a testing engine. It’s still very much in development and I won’t explain more about it for now. I just wanted to show you the sample of the current report it generates.

It’s a 1/2 MB of some HTML, JavaScript and mostly json data. It will be smaller with next updates. Press the blue arrow buttons to get to next requests. It skips the static ones like loading css/images/js. It is work in progress so there are bugs and ghost html code inthere. It’s done in REBOL. The JavaScript in report uses jsgoo library.

But why didn’t I use existing testing engines?
Yes, there are things like Watir, Selenium, Windmill, Twill. And they are cool things, and I might use them too in some cases. But my goals here are a little different (which is not yet that well implemented). I want to test the core of the app – the backend/it’s API mostly, I do not want to test on the level of HTML DOM, forms, texts, clicks in the browser, etc..

At this year’s pycon, the guys that created Windmill testing framework told, that they started making it because they were using Selenium and each week (or something) 30% of their tests failed. Because they had a constantly evolving app. So they needed a more flexible testing framework that they could change quicker. When I heard that I thought to myself:

“If 30% of your tests failed each week, maybe you are testing on the wrong level. I can’t imagine that 30% of your core app changes each week. the design/html representation does maybe?”