You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Connected to #35, but preexisting. Using embedded argument keywords for hook stubs and overrides in Robot Framework enables a great deal of flexibility when reusing code, but it is very brittle. As defined, hook overrides are one typo away from being ignored during execution (no Before my system benchmark case iteration hook will be found if defined as Before my sstem benchmark case iteration), which at best will result in cryptic failures and at worst will fly by silently.
This is unacceptable from a usability POV. LAMBKIN must detect and flag these cases accordingly.
Implementation considerations
There are two different conditions that need to be flagged: extending non-existent functionality and failing to override appropriately. The former can be handled by removing (no op) stubs for extension. That's easy. The later is trickier. Removing stubs would force lots of boilerplate on users, and some overrides may simply be unused (e.g. when provided by a library) which on its own does not imply user error. One possible restriction to problem scope is to only audit keywords defined in a user-defined set of source files (or the top-level suite source file by default). A Robot Framework listener could instrument keywords behind scenes so as to ensure that all are invoked at least once. Tags may be used to explicitly disable this feature in selected keywords.
The text was updated successfully, but these errors were encountered:
Feature description
Connected to #35, but preexisting. Using embedded argument keywords for hook stubs and overrides in Robot Framework enables a great deal of flexibility when reusing code, but it is very brittle. As defined, hook overrides are one typo away from being ignored during execution (no
Before my system benchmark case iteration
hook will be found if defined asBefore my sstem benchmark case iteration
), which at best will result in cryptic failures and at worst will fly by silently.This is unacceptable from a usability POV. LAMBKIN must detect and flag these cases accordingly.
Implementation considerations
There are two different conditions that need to be flagged: extending non-existent functionality and failing to override appropriately. The former can be handled by removing (no op) stubs for extension. That's easy. The later is trickier. Removing stubs would force lots of boilerplate on users, and some overrides may simply be unused (e.g. when provided by a library) which on its own does not imply user error. One possible restriction to problem scope is to only audit keywords defined in a user-defined set of source files (or the top-level suite source file by default). A Robot Framework listener could instrument keywords behind scenes so as to ensure that all are invoked at least once. Tags may be used to explicitly disable this feature in selected keywords.
The text was updated successfully, but these errors were encountered: