Test writing policy for Sublime and Shell

[Alexander Dymo]

On Saturday 03 May 2008 09:04:54 Vladimir Prus wrote:
> 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.

This is actually not the case. For instance, when you write user visible 
feature, you expect it to work no matter how mature current code is. And it 
usually works when you try it yourself before committing, right?. So it's 
quite natural to write the test for it.

As I wrote in the HOWTO, we need not to test deep internals and we'll be fine 
with UI tests. Instead, we need to test user visible actions and check for 
user visible results.

Examples:
1) test document opening
	- open document
	- check that we have one more doc
	- check that we have one more visible view
2) test splitting
	- check mainwindow layout before
	- split
	- check mainwindow layout after
3) area loading/restoration
	- setup area / mainwindow (open stuff, resize it, etc.)
	- save area
	- load area
	- check view layout, sizes, etc. 

> I'll try that. However, you probably know that the most important thing
> about testing is a sensible testing infrastructure. 
QTestLib is ok, our shell test infrastructure is quite ok as well. 
There's one known shortcomming though - we have no infrastructure to test 
plugin controller atm.

> If the current testing 
> infrastructure proves awkward, I'll either poke you hard, or stop writing
> tests :-)
Please do the former thing ;)

> 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?
I'm working on that...