4 ms·

> the RF developers have been uninterested in incorporating this aspect of test Have they been asked? I had the same problem and had different solutions built

• elevation 4y ago
  Pekka has previously expressed that test resource management should not be included in the core and is better implemented as separate keywords. One example would be the limited resource management that Pabot supports (basically a single global semaphore that tests can increment/decrement through a pair of keywords.) The problem with 3-rd party keyword-based solutions is that the resource acquisition becomes a part of the test process and could a test report to look like "ran for 6 minutes, then failed" when what really happened is the actual test couldn't be run at all because resources weren't found. It would be nice to be able to queue tests based on the resources they'll need. Also, another feature that's more difficult with custom implementations is static analysis of the test base. If resource requests were a declarative part of the RF language (much like tags) you could do things like "run all tests that exercise resource X" or "run all tests except those which require more than one Y". This is technically possible with a keyword library but requires an additional global lexing pass of the entire test base, and this is the kind of logic you don't want to decouple from RF and it's test discovery behavior. Perhaps Pekka can be won over in the future.