On 08/09/2012 03:29 PM, Mikolaj Izdebski wrote:
> Examples are good, especially examples like these. To be fair, I
hadn't
> realized how simple things could be. Have you implemented this using a
> json plugin handling the communication between "your" plugins and f-r?!
Yes, I have implemented this as a single JSON plugin which basically:
1) asks F-R for all possible info (spec file scetions etc)
2) extracts more stuff on disk
3) reads metadata of all scripts
4) orders scripts basing on their dependencies
5) executes individual scripts
6) returns one reply to F-R containing results of all tests
I raised the issue to simply drop the json api in another message. One
strategy might be to support either "advanced" plugins written in
python or "simple" ones following your approach here. This means that if
we could reimplement your json plugin in python the json interface could
be dropped and we would have:
- python plugins: multiple tests, attachment handling, access to
internal python classes.
- "simple" plugins: one test per file, simplified registration, no
attachments.
To me, this looks attractive. Let's hope your employer sees the benefits
in opening up the sources.
In any case, the modelling of a test needs an overhaul both in python
and to some extent also for the simple ones. Things like
dependencies/execution order, access to other tests, selecting tests to
run. The registration of plugin tests should really be done also by tje
python ones...
--alec