Test writing policy for Sublime and Shell

[Alexander Dymo]

Our UI development recently become the catch-up game. New features got added, 
existing features got broken then fixed again. 

This is not acceptable if we ever want to keep KDevelop4 in usable state. I 
understand that writing new code is fun, but let's do some small amount of 
additional work to assure that once something in the UI works, we'll never 
break it again.

In KDevelop 3 times the simpleideal UI I wrote was so simple so I could keep 
it completely in my head. This is not the case in KDevelop4. We have much 
complex UI. And it's not only because we wrote too much code (we did) but 
because we want it to do way more than before. At this moment I believe that 
there's no person who has the clear and complete picture of both our UI model 
and UI code and can fix everything in a couple of minutes.

As I am currently maintaining our UI in sublime/ and shell/ and I'm the guy to 
be kicked when UI is broken, I'd like to introduce the new policy for Sublime 
and Shell. 

So, please:

1) before commiting to sublime/ and/or shell/ please run "make test" in BOTH 
sublime/ and shell/ to ensure that existing functionality is not broken

2) for each new feature please write a test that covers all functionality that 
is supposed to work

3) for each non-trivial bugfix please write a small test function (or modify 
existing one) that breaks without your bugfix and passes with your bugfix


PS: 
Small HOWTO on UI testing: 
http://www.kdevelop.org/mediawiki/index.php/How_To_Write_UI_Tests 

Also feel free to ping me every time you need more help with tests.