QA/Mozmill Test Automation/Shared Modules: Difference between revisions

QA/Mozmill Test Automation/Shared Modules (view source)

Revision as of 20:19, 22 April 2010

1,569 bytes added , 22 April 2010

→‎Identifying Requirements

Whimboo

canmove, Confirmed users, Bureaucrats and Sysops emeriti

4,747

edits

@@ Line 33: / Line 33: @@
 ===Identifying Requirements===
+This part is probably not trivial if you are doing it the first time. That's why we want to offer some help for the requirements definition process. By following the steps below you will be able to put a good list of items together.
+. Each of the tests will interact with a couple of ui elements. All those elements can be accessed in different ways. The easiest way is definitely its node id. But there are probably more elements which can't be reached by that method and requires a complex lookup expression. As a test writer you don't wanna be confronted with such a research task because it requires knowledge about the DOM and tools like the [https://addons.mozilla.org/de/firefox/addon/6622 DOM inspector]. Instead you want to simply use those elements and create sequential steps of actions. To be able to do that, the shared module has to give access to all elements in the same simple manner by only specifying the elements name and eventually an index. As result the getElement function has been added to all shared modules and has to be used to retrieve elements.
+. Tests from the same subgroup normally have similar actions which have to be performed to get into a given state. Those single steps shouldn't be performed again and again by the tests itself. Instead a function should be created in the shared module which combines those steps in a single call.
+. Sometimes the new shared module can have dependencies to other shared modules. Take the AddonsAPI as an example. It reads and writes some preferences and needs functions from the PrefsAPI.
 ===Implementation===
 ===Using a Shared Module===