With little or none previous experience of testing, I’m looking into adding automated testing to a continuous integration process of SharePoint applications. I’ve learned how this can be achieved using coded UI tests that are run before deployment and during the build and I’ve used Selenium with Java before, where we didn’t record any scenarios but instead wrote tests by hand, identifying elements in the GUI and asserting results. With this little experience, I have a few questions about UI testing.
- Is it possible to write test methods that can be applied on several different applications, such as testing buttons etc. or is this something that has to be written for each project, since the results of button click may vary? I assume that this would require following a specific standard .
- Are there any UI testing methods that can be generalized and applied to all projects that go through a certain build, or is the same here that all UI tests must be written specifically for that application?
Is it possible? Sure it is.
Is it recommended? That’s a tougher question – automated tests are created to validate the functionality of your application. Generic testing can only test generic functionality.
I can see two main use-cases where you might find yourself contemplating on generic testing:
- Testing applications which use the same boilerplate functionality, because they use the same library, framework, etc.
- Testing application which should abide to the same standards which were decided in some meta-application policy in your company.
For the first case, I think the correct approach is to unit test the library/framework in the context of that library or framework, and leave only high-level sanity/integration tests on each application, to see that it uses that library correctly. There is no need to test the same code in different applications – it is the same code, after all…
For the second case, your company might decide to write generic acceptance tests to make sure that every application adheres to the needed standards, in which case, it seems reasonable from the point of view of the QA team to run the same tests on every application, given that the requirements and tests are robust enough to handle applications which might be very different on many other aspects.
You could share a low level layer of functionality for different applications (that at least have to be based on the same technology, like Web, WPF, … or a superset thereof).
Actually, you can think of many UI testing tools as this (and this is why it often does not make sense for you to write that layer). Then you have to separate the identification part from the control part:
- all buttons are clickable (if they are enabled, so they have an “enabled” property and a “click” function)
- you distinguish 2 buttons via their UI path: /application1/greatDialog/ButtonOk and /application2/superDialog/subGrouping/ButtonMaybe
You only save little code though, since applications typically behave very differently. Depends all on how much is shared in the UI and how similar the usage is.