Test writing policy for Sublime and Shell

[Vladimir Prus]

On Saturday 03 May 2008 02:42:07 Alexander Dymo wrote:
> Our UI development recently become the catch-up game. New features got added, 
> existing features got broken then fixed again.

This is interesting theory -- which is only true if you assume that whatever
we had before hackathon was a feature ;-) 

Seriously, there's "write it all quickly" stage (or prototyping stage) and 
there's stabilization stage, and given the current state of UI, we're more 
like in prototyping stage. Therefore, one should expect the tests to be
either trivial, or have to be revised annoyingly often.

> 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

I'll try that. However, you probably know that the most important thing about
testing is a sensible testing infrastructure. If the current testing infrastructure
proves awkward, I'll either poke you hard, or stop writing tests :-)

- Volodya
 
P.S.

> As I am currently maintaining our UI in sublime/ and shell/ and I'm the guy to 
> be kicked when UI is broken,

So far, you're most often kicked for UI that does not do anything interesting :-)
Which brings me to my regular point -- where are breadcrumbs?