Greg, there certainly are apps that lend themselves to e2e testing where UI paths are limited and well defined. Your app may fall in this category regardless of number of pages. Here is an approach from Sauce Labs: https://saucelabs.com/blog/using-bdd-to-automate-testing-of-single-page-apps-spa-in-clinical-trials
On the other hand, imagine Facebook with it's multitudinous pages and options where their e2e is a combination of well defined unit, integration, and human testing. Their <https://www.quora.com/What-kind-of-automated-testing-does-Facebook-do> e2e automation covers critical areas like privacy--but certainly not everything. So you may want to consider a few questions in e2e/functional testing strategy: - Can the functional tests be well-defined and 'capped' to a 'limited' number? Will this result in appropriate 'coverage' percentage (the e2e tests cover the 'critical' user experiences and discard others). Imagine the number of protractor or selenium tests to provide acceptable coverage. Also, can the tests be so well defined that you have good confidence of how changes in area A affect area B? Can you well-define the vertical (User A buys a widget) vs horizontal (User A must register/login, add payment info, and be able to buy any widget) tests so the combination maximize coverage? This is hard. - Do you have enough internal time and resources to accommodate changed (frequent?) business requirements to maintain/upgrade e2e tests in addition to the code itself? - How does e2e automation time, labor, and costs compare with with the equivalent manual/human? Note, a trusted and competent human tester provides 'intuitive tests' that might be missed in the automated tests for one reason or another. Note, you (a human) can capture and save a test for future automation using tools like Selenium. The coverage, as such, is as good as your imagination and understanding of what various paths a user can take to achieve things (often the same thing). Unit tests, on the other hand, are better defined and don't suffer with this by nature. As for an AJS SPA, that's what Protractor (based on Selenium WebDriver anyway) is for. On Tuesday, February 21, 2017 at 10:52:11 AM UTC-5, Greg Finzer wrote: > > *Background:* > We have an Angular 1 application that is 50 screens. We will be adding > 164 more screens in Angular 2. The back end is C# with WCF. There are > currently zero tests. We are using Team City for our build server. > > I have been doing self training for a couple weeks now on Angular 1 and > Angular 2. I understand that it is possible to write tests for Angular 1 > or Angular 2 using JavaScript, Jasmine, Protractor, and Selenium. > > We need to create a baseline of tests for the 50 screens. One test per > screen that performs the submit, search, etc. > > *Question* > What other tools are available that would make it easier to write user > interface tests? Can we use Selnium with C# to test the Angular 2 User > Interface? Is it even possible to do that since it is an Single Page > Application and the DOM is built up dynamically? The client also owns HP > Quality Center/ALM so is it possible to do QTP testing? > > > > > > -- You received this message because you are subscribed to the Google Groups "Angular and AngularJS discussion" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/angular. For more options, visit https://groups.google.com/d/optout.
