define test cases in JSON" - now I hope that I've finally got it. Now it all makes sense, the puzzle is complete in my head. Have just read the other answers, I also agree with guys. It makes sense to have common logic (serialize/deserialize methods, config map, etc.) be centralized in the common ancestor class.
If I understand you correctly, you're in charge to take a decision or to influence it greatly. And your main goal actually is "reduced Dev effort" and "write a test case with just JSON without worrying about selenium driver and accompanying code for basic render and submit". Not to develop your own "small framework for configuration based selenium testing" (maybe just because it's fun, everyone of us likes challenges and building small tools), but to reduce test effort.
Then I can suggest two tools that could be even better than you're expecting:
- geb. while I'm mostly working with groovy, it would be surprise if I wouldn't recommend "geb". If you combine "defining common logic in ancestor" approach and geb's dsl features, groovy dsl features (enhance geb dsl even more), you could end up with almost user readable test cases. Especially for common templated products.
http://www.gebish.org/
- met with these guys at local event, they are developing amazing testing tool. just check the demo video. their site is not very descriptive, there's much of "market leader" and "number one product in the world" kind of miningless phrases.
https://www.youtube.com/watch?v=MJErSHcQVNY
https://testein.com/
I am just an entry level engineer, but yes I can influence and propose the adoption. I will look into these. Thank you.
Обсуждают сегодня