How do you test GUI elements on your sublime text plugins?
Till now my take on it has been having 2 layers on my plugins:
-
The first layer, the core, where you’ll be able to test outside the Sublime Text environment, it will contain all non-related Sublime elements, it’s “decoupled” from ST code. Said otherwise, if you were to test this layer/package on a normal python distribution you could it without any problems, designing the test-suite for this layer is a non-brain. I could use some of the zillion testing frameworks out there although I’ve decided unittesting builtin one is good enough for me.
-
The second layer, sublime commands and sublime helpers, this layer contain the plugin themselves and related sublime code. I try to design these plugins to be as thin as possible. As a cardinal rule, they should contain strictly “sublime” code (dialogs, commands, sublime_api, …) and use the 1st layer, where basically all the meat (hard logic… is this a right English term?) lives.
That said, till now this approach was good enough but I’d like to go on one step further and testing the whole thing even better. Problem remains like this, when the number of commands of your package grows is too big you’ll end up wasting quite a lot of time manually testing these commands and that’s definitely not a good way to go, at the time you’re manually testing something you should ask yourself whether there is a better approach to it.
So yeah, i’m not really sure how to optimize the current workflow. On Qt land, there is quite a nice testing framework allowing you to make UI testing a very pleasant experience but I’m pretty sure ST doesn’t have any similar framework like that, which is perfectly understandable and obvious.
Anyway, let’s assume we don’t have any UI-testing-framework, but still… what’d be your advice on this one to make smoother the pre-commit-testing stage?