Today I've upgraded the most important and visible part of my PC - display :)

New 226BW is now staying on my desk. It's 22 inch wide screen therefore I have a lot of screen now, I can organize my windows without overlapping :) also Firefox full screen makes no sense anymore.

I'm actually thinking now to plug it together with the old 19'' one.

DSL in Automated acceptance testing

I found a very interesting post on the Google Testing Blog
concerning experiences in Automated Acceptance Testing, we also call it end2end testing. It's was very interesting reading, because we share more or less the same experience. We had a very long discussions with my colleague from the "testing department" about how much the automated acceptance tests worth.
He was writing his Master Thesis on this topic. He was using Mercury Winrunner tool for automation of the Java Swing GUIs (Netbeans based). He had very interesting experiences and the thesis was very well done and interesting to read (I can't find it right now, may be I'll post a link to it later). In the end he comes to the heuristics, that for his project it takes 4 times longer to automate and maintain automated test than to write and execute test once, therefore the rule of thumb for his project was if the test is executed less than 4 times then it makes no sense to automate it. Basically it means that if in Waterfall model project has one release per year and feature will not survive more than 4 releases then it is not worth to automate it.

Such statements and heuristics are highly subjective. There are some test cases that will take 10 to 20 times longer to automate than to execute manually (example of it see below).
I completely agree with Markus about maintenance costs of the tests and also faulty failures, it's a very big problem that may also affect our decisions where automate and where not.

Also as Markus mentioned very right : "[test automation] turned into art of engineering ... we come up with best-practices" and if we apply principle of treating test code as production code then we decrease significance of the problems with automated testing hence increase the value of it.

I've played with test automation tools allot and for our most recent project we need to speedup the development process, therefore it was decided to create automated acceptance tests. Fortunately application we developed was a Web-based therefore we had a wide palette of tools at our hands (with ordinary GUI it's much more complex nowadays). Since we haven't used any AJAX and/or Javascript in our application we've chosen HttpUnit and derivatives of that (JWebUnit). After creation of the first tests we simply apply the practices we used for our production code to evolve it - refactor, refactor and refactor. After some two or more evolution steps we've got to the conclusion that:

• We have refactored common parts of the tests to the kind of testing framework.
• We might need to start writing unit tests for automated tests :)

The most interesting part is off course our testing framework, because it provide an abstraction layer over the application UI, and since "The behavior of the program should be internally and externally consistent" we essentially recreate application domain model in our automated testing framework. For example in our application we have a report tree, therefore in our testing framework we have a generic tree interface that represents a report tree in the application UI, we can inspect it via the methods of the "ui tree" that are essentially the same methods as tree that is used inside application, internally.

With the testing framework we've got some very nice advantages:

• Tests are more stable, since testing framework abstract the details of the UI that are likely to be changed. Which means that in case we change a tree representation we only need to change the framework and all tests will be unaffected.
• Tests have become much smaller and concise. Since tests are now operating on the very clean application domain (see discussion below about DSL) therefore even people with little test-automation experience can write them, and the most important understand and modify existing testcases which is the prerequisite for collective code ownership.
• Framework includes shared fixtures that enable us to create tests even simpler without looking into the details of the application page flow.

What was also very interesting to see, is that one essential aspect of the testing framework that it is application domain specific, automated testcases operates on the domain terms and domain objects the same as any other written test cases for manual execution. This fact off course make the framework not reusable but enable us to think about simple DSL to simplify test cases creation and modification.

At the end it was a big success, application we created need to work on 5 different platforms instead of planned 1, therefore by reducing regression testing efforts from 2 man/month to 30 minutes we benefit allot.

Now we are thinking about expanding it to the following directions:

• Try to create a external/internal DSL, something like JRuby or Groovy based
• So far we hadn't had big number of false failures , however if we will have them then could do a testing of the testing framework, i.e. before executing tests check that testing framework match the interface of the application.
  

ICQ - MUST DIE! DIE IN HELL!

Unfortunately my English is not good enough to express how I hate ICQ

For me it's one of the worst programms ever written by human. I hate it, I hate it!
It was a piece of shit not very good programm before, and fortunately I managed to avoid it, but recently it was installed on my PC by other person.

What can I say... it become even worse! It's amaizing what are those guys doing. How invasive they are.

After intallation together with the stupid browser toolbar this sh.tty tool made following changes:

Add it's toolbar, enabled by default, with the nasty and ugly icons they have (Icons are really UGLY!)

Changed default search engine to ICQ - why the h..ll they do it!! Why do I need this stupid search! It's amaizing!

Changed START PAGE to start.icq.com

Period.

You can imagine how long this ICQ was installed on my PC after that. Yes, 3 more seconds.

On it's last breath it was trying to open IE (my default browser is Firefox) and show me the feedback page, where I can express my feeling. I've done that.

I really hope this tool will die soon.

Design evolution

There are two significantly different approaches to the SW design (or SW architecture in small), evolution and revolution approach. Under evolution approach I understand creation of simplest possible solution that will work and satisfy requirements and then evolving it over time. Revolution approach will include planning phase which is much longer than in evolution case and therefore will bring some bigger architecture/design parts up front.

You can think about tree search algorithm, deep search and wide search, deep search is like quick prototyping or tracer bullets (copyright pragmatic programmers), wide search will solve one level of design at time.

So, in short, I really hate the design revolution, it is definitely needed sometime but evolution is much better.

I'm involved in the project where whole system is not even run, but we already have megabytes of the source code with 100 different features inside, but no end2end usecases are implemented yet.

It is always a trade off in some sense, evolving design is very hard, sometimes I'm thinking that I would better spend more time on this particular level (wide search) than going down or up (deep search). But most of the time it's bed temptation.

There are some clear prerequisites for the design evolution - aka refactoring, and it is:

GOOD UNIT TESTS

I can't really express how important it is. Without the unit test coverage system can't evolve, and to be honest sometimes we need to do a revolution to enable evolution.

Hm...

Evil Eclipse feature

Just found how nice Eclipse feature called Sort Members destroyed Hibernate mapping annotations

We had a model in our source code with annotations on it to declare a persistency options, something like:

/** List of all bets */
@OneToMany(fetch = FetchType.LAZY, cascade = { CascadeType.ALL }, mappedBy = "event")
private final List bets = new ArrayList();

Since I have another nice feature of Eclipse enabled all the time, it's Save Actions, every time I save file some actions are performed, such as Organize Imports, Formatting, Sort members.

So at the end I haven't really noticed that I've destroyed part of the mapping declaration, since Sort Members is somehow not working very well with annotations (I guess it sort annotations separately from the element they attached to :) ).

So, be aware about evil features.

Update:
Our mapping testcases found the problem and CruiseControl reported about it 1 minute after the commit. :) +1 to Unit testing and Continuous Integration

My first post in my new blog. Let's see how often I'll post here :)

Main topics I expect in my blog are:

1. SW Development
2. Agility
3. MDA (EMF?)

Hm.. some more staff...