- *
- *
- * ## Locating Elements
- *
- * Most methods in this module that operate on a DOM element (e.g. `click`) accept a locator as the first argument, which can be either a string or an array.
- *
- * If the locator is an array, it should have a single element, with the key signifying the locator type (`id`, `name`, `css`, `xpath`, `link`, or `class`) and the value being the locator itself. This is called a "strict" locator. Examples:
- *
- * * `['id' => 'foo']` matches `<div id="foo">`
- * * `['name' => 'foo']` matches `<div name="foo">`
- * * `['css' => 'input[type=input][value=foo]']` matches `<input type="input" value="foo">`
- * * `['xpath' => "//input[@type='submit'][contains(@value, 'foo')]"]` matches `<input type="submit" value="foobar">`
- * * `['link' => 'Click here']` matches `<a href="google.com">Click here</a>`
- * * `['class' => 'foo']` matches `<div class="foo">`
- *
- * Writing good locators can be tricky. The Mozilla team has written an excellent guide titled [Writing reliable locators for Selenium and WebDriver tests](https://blog.mozilla.org/webqa/2013/09/26/writing-reliable-locators-for-selenium-and-webdriver-tests/).
- *
- * If you prefer, you may also pass a string for the locator. This is called a "fuzzy" locator. In this case, Codeception uses a a variety of heuristics (depending on the exact method called) to determine what element you're referring to. For example, here's the heuristic used for the `submitForm` method:
- *
- * 1. Does the locator look like an ID selector (e.g. "#foo")? If so, try to find a form matching that ID.
- * 2. If nothing found, check if locator looks like a CSS selector. If so, run it.
