I have been reading the shared documentation:
It is a good work what you have done here but it looks like a little confuse due the 90% of the doc is talking about technical stuff.
This technical information is gonna be helpful for the development but in a "specification" time we should focus in "what we need" and not in "how to implement it"..
Also Juan has pointed me that we can not use the name BrowserShooter because is misunderstanding its possibilities. BrowserShooter is not a VM screenshot system but a Multi-Browser test system, with a lot of configuration possibilites we are still requesting as missing. For now on we can use the key name "TESTA" for this project.. or any other thing you suggest :)
Trying to summarize I think (after a long talk with Juan) this is what we need (and is not already supported by BrowserShooter):
- Test Suites: definition, execution and log
- Browsers: configuration of the available browsers and the access to them
- Extensible command system
Would be nice to have a definition of what a "test suite" is.
Also a real example with real data.
In my head a test-suite is no more than a collection of "tests" executed in a collection of "browsers".
I have written a possible example of a "test suite" definition:
Please check the "suites" section.
Our TESTA project will not execute independent "tests" (as BrowserShooter does now) but "test-suites".
The external command can be something like:
$ testa.rb <config_file.yml> [<concrete_suite>]
Where <concrete_suite> is optional and if not present all suites will be executed.
After the "test-suite" execution the logs will be on:
/<output_path>/<time_stamp>/<suite_name>/<test_name>/logs/logs.csv
/<output_path>/<time_stamp>/<suite_name>/<test_name>/shots/*.png
I again would like you to check this file:
Especially the "browsers" section and tell me which possibilities are missing.
This is a very tricky point, I feel two forces facing here:
- Define the tests as pure Ruby
- Define the tests in a "custom" very simple DSL
As Juan has pointed me, an extensible command system, like a plugin system or something like this can satisfy both needs:
- We keep the tests commands based in a custom very simple DSL
- This DSL can be extended with new commands that execute pure Ruby
With this plugin system we are also solving the need of "meta commands", about what Juan has talked to me.
I will like to keep the "test-commands" still in the yaml, but know knowing that these commands can execute "custom commands".
I'm wondering if what you name "PageObject" is exactly what I'm naming "Extensible command system". If not I need more explanation about it.