Test writing policy for Sublime and Shell
dymo at ukrpost.ua
Fri May 2 22:42:07 UTC 2008
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
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
Small HOWTO on UI testing:
Also feel free to ping me every time you need more help with tests.
More information about the KDevelop-devel