Hot answers tagged


Your boss doesn't want a flat "No" or to hear their request is impractical. They want to reduce the risk of releasing changes to the application. Make your boss choose your priorities, that is one of the roles of a manager. Add scenarios based on team knowledge and work with your boss to rank them by risk. Implement top priority scenarios Go back to ...


John Ruberto wrote an article some years ago on Stickyminds entitled, "Is 100% Unit Test Coverage Enough?". The article can be found here: In it he presents the argument that there are different kinds of coverage. One could cover 100% of requirements, but that doesn't include ...


It's always good to use numbers to make your point- There are N models and sub models of iPhones (for some applications you should also count the phone's network sub-type), each with M available iOS versions and sub versions (this is not entirely accurate, some models and iOS versions don't work together, but never mind that now) Older iOS versions needs ...


I've spent a fair bit of time working on safety-related software. People die if the software fails, kind of safety. The first thing to note is that we had 100% test coverage of requirements. However that didn't have to be automated, sometimes because it wasn't practical, and sometimes because it wasn't physically possible. No safety-related standard ...


No, that's not true at all; you can definitely add your own id attributes to elements rendered in React components. id is listed as a supported DOM attribute in the docs. Yes, in cases where components are reused, the developers will have to allow for something unique to be passed in, but that's exactly how e.g. Material-UI already does this: https://...


It depends what they consider 100%, but my basic answer would be 'no' especially if these are UI level tests. Tests at this level are slow and expensive to write and maintain. It looks like you know this already, but write tests that cover the broad paths through the application/its functionality.


Assumption: I believe we are just talking here on e2e testing of React using protractor. Generalized JavaScript Framework agnostic to any Frontend frameworks IMHO, in such cases we should strive to generalize the framework on JavaScript level taking advantage of latest ESx features(like async/await for promise resolution) .The framework should be agnostic ...


Welcome to managing your manager. I agree with the sentiment that your boss doesn't want to hear a "No". That's not quite verbose enough. But, the answer is almost assuredly a "No". What you need is a way to communicate how and why to limit your test scope. Even if you tested all the permutations of every make-model, screen-size and OS, you will soon see ...


WaitForExit() checks only for the presence of and not the visibility . You could use $(selector).waitForDisplayed instead . And also ensure there is no other element with the same selector


We don't use Detox, only Jest for our React Native app. We have integrated Allure in our Jenkins build, and are fairly happy with it. Whether this helps your situation I can't say, as I am not fully clear what exact problem you are having.... ;-)


If you simply abstract page components and behavior on an object, you are using the Page Object Model - do not get confused if you are dealing with "screens", not "pages"... object = { button = () => find('button'), save = () => this.button().click() } There are some libraries for Page Objects specifically for React.

Only top voted, non community-wiki answers of a minimum length are eligible