devTrove

Sometimes you have to deal with all of these: user stories which are nothing else but simple requirements for some input fields;  requirement to write e2e tests, where e2e is understood as "everything we can do using GUI"; phrase "we should use Cucumber because... just because this is the way we are used to do".  We've started like this in one of our projects. I'm really happy finally we managed to get rid of "Cucumber for everything" requirement and are not using it for GUI component testing anymore. But we used to do this and here's some bad experience. Imagine you have a "user story" for a input field called "Customer Reference", which looks something like this (in fact, it was more complex, but the main idea remains the same): As a user I want to be able to enter customer reference number. Acceptance criteria: - number may contain alphanumeric symbols (including spaces) - number can be up to 20 symbols length ...

Since end of October I switched from test automation using Groovy, Geb, Spock and SoapUI to test automation using Protractor, Cucumber and Jasmine. Different apps, different tools, new challenges and new knowledge. The biggest challenge is promises. Lots of samples on the web about promise chaining. The small "problem" - most of those samples are for browser interaction related functions. Well, that's what we are dealing most in e2e tests. But what if those simple functions are not enough, if you need to write some functions of your own which return non-browser related promises? E.g., just to compare some values of complex structure and return "true" or "false"? Or anything else not browser related. If you are new to this kind of testing, here's where "adventures" begin. When you don't know what to google for, it's not so easy to find out you are looking for a thing named "browser control flow". What it is about? Wel...