Oz is a behavioral web-ui testing framework developed to reduce test maintenance by using a predictive model rather than a scriptive model when writing tests.
Apache License 2.0
23
stars
7
forks
source link
[Gemification] Wrap oz components in an Oz namespace #172
The purpose of this change is to reduce the footprint oz leaves when defining constants in the global namespace. As per my conversations with donny, we'll call the namespace Oz, because it's nice and simple. (While there exists another gem already named oz, it currently does not utilize a namespace at all as it only contains a single ruby bin, that executes in main)
In prior state we were highly vulnerable to name conflicts because the entirety of Oz just sits directly off of main, eg, we couldn't have a class called Logger in our library because it would conflict with core ruby logger.
Next goals after this will be to fix our project structure so we don't accidentally clobber core-lib files, turning oz into an actual gem and separating example out into its own repo.
Another change i snuck in here was to not auto load our step definitions. I did this because cucumber has zero tolerance for duplicate step definitions, once a definition has been defined, you cannot redefine it without some serious meta magic. This means if we have a step defined named "I see that all the content on the page is correct", no one who is consuming our library would ever be able to define another version of that step (enabling ambiguous step handling isn't a great solution because it can make which step it decides to use local env dependent which causes all sorts of debugging headaches.)
The step definitions will be loadable explicitly by someone consuming the library by simply requiring 'oz/step_definitions'
The purpose of this change is to reduce the footprint oz leaves when defining constants in the global namespace. As per my conversations with donny, we'll call the namespace Oz, because it's nice and simple. (While there exists another gem already named oz, it currently does not utilize a namespace at all as it only contains a single ruby bin, that executes in main)
In prior state we were highly vulnerable to name conflicts because the entirety of Oz just sits directly off of main, eg, we couldn't have a class called Logger in our library because it would conflict with core ruby logger.
As an added bonus this puts us in compliance with the suggestions outlined in https://guides.rubygems.org/
Next goals after this will be to fix our project structure so we don't accidentally clobber core-lib files, turning oz into an actual gem and separating example out into its own repo.
Another change i snuck in here was to not auto load our step definitions. I did this because cucumber has zero tolerance for duplicate step definitions, once a definition has been defined, you cannot redefine it without some serious meta magic. This means if we have a step defined named "I see that all the content on the page is correct", no one who is consuming our library would ever be able to define another version of that step (enabling ambiguous step handling isn't a great solution because it can make which step it decides to use local env dependent which causes all sorts of debugging headaches.)
The step definitions will be loadable explicitly by someone consuming the library by simply requiring 'oz/step_definitions'