I find simplelenium to be exactly what we were trying to reach on a previous project, that is, a - well - simple wrapper that handles those silly timing issues. That said, at first we still had problems with our own "retry" solution: we had no clue about why exactly our test failed: was the target element missing, and if not what did it look like. So we improved our solution a bit to bring back the nice feedback of a simple "assertEqual": we attempted for each kind of check to give a maximum of details about the target element when it was actually found but did not pass the check.
Hi David,
I find simplelenium to be exactly what we were trying to reach on a previous project, that is, a - well - simple wrapper that handles those silly timing issues. That said, at first we still had problems with our own "retry" solution: we had no clue about why exactly our test failed: was the target element missing, and if not what did it look like. So we improved our solution a bit to bring back the nice feedback of a simple "assertEqual": we attempted for each kind of check to give a maximum of details about the target element when it was actually found but did not pass the check.
I propose you an example of such a feature, implemented on your "contain" verification. If you're curious, I also had a try at implementing it in a lambda fashion, but that was a bit silly (see https://github.com/ndemengel/simplelenium/compare/feature;failure-clue-original-design?expand=1).
If that suits you, I can migrate the other verifications as well.