CubicEx architecture

[Clément Beaujoin]

Hi, before Ronald Mathies started CubicEx, i had an other way to
provide custom test step.

I created a public class CubicBaseTestCase extends SeleneseTestCase.
This class provides methods like :

verifyElementValueNotNull
verifyElementValueNotBlank
....
public void verifyCursorPosition(String locator, int position) throws
AssertionFailedError{
assertEquals(selenium.getCursorPosition(locator),position);
}

It consists in improving the basic SelenseTestCase, and could be an
update of this class. Moreover at this level could be implemented
verifyException ...


Then each custom test step could look something like this class :

public class VerifyCursorPosition extends CubicBaseTestCase implements
ICustomTestStep {

public void execute(Map<String, String> arguments, IElementContext
context,
Selenium selenium) throws Exception {
this.selenium=selenium;
String locator;
int position;
for(String argument: arguments.values())
{
locator = argument.substring(0,argument.indexOf(","));
position = Integer.valueOf(argument.substring(argument.indexOf(",")
+1));
verifyCursorPosition(locator,position);
}
}
}

What do you think of it ?

[Ronald Mathies]

Hi Clément,

Creating a basic class for all tests can indeed be very useful,
currently i don't test well enough if the given properties / arguments
are valid.
A lot of functionality like getting the properties / arguments i
placed in a static class, for one reason to promote re-use of
properties and to easily handle
variables that are stored in memory.

So for example your custom test would look like this (in the current
code state):

public class VerifyCursorPosition implements ICustomTestStep {

public void execute(Map<String, String> arguments,
IElementContext> context, Selenium selenium) throws Exception {

final String locator = ArgumentUtils.getTarget(arguments);
final int position = ArgumentUtils.getPosition(arguments); //
Could handle variables like ${var}

assertEquals(selenium.getCursorPosition(locator), position);
}
}


Handling the VerifyException in that way and giving the idea of
extending the SeleneTestCase is also very interesting (http://
jira.openqa.org/browse/CT-89), i am going to try this out and see what
happens when i use verifyEquals for example, does it stop the test or
does the test continue and do i see warnings in the report?

Methods like verifyElementValueNotNull and verifyElementValueNotBlank
would be indeed nice to test if an element actually does exist when we
really expect it to exist (not WaitForElement for example which
doesn't expect it to exist directly).

[Clément Beaujoin]

Currently i had already developed theses methods :

verifyElementValueNotNull(String)
verifyElementValueNotBlank(String)
verifyElementValueNotEmpty(String)
verifyElementPresent(String)
verifyElementNotPresent(String)
verifyCountElementAt(String, int)
verifyCountElementAtInferiorAt(String, int)
verifyCountElementAtSuperiorAt(String, int)
verifyEqualsTextAt(String, String)
verifyNotEqualsTextAt(String, String)
verifyLayer(String, String)
verifyCurrentLocation(String)
verifyRedirectionLink(String, String)
verifyElementVisible(String)
verifyElementNotVisible(String)
verifyRedirectionSelect(String, String, String)
verifyCookiePresent(String)
verifyElementTextContains(String, String)
verifyAttribute(String, String)
verifyVisible(String)
verifyNotVisible(String)
verifyValue(String, String)
verifyNotValue(String, String)
verifyEval(String, String)
verifyEditable(String)
verifyNotEditable(String)
verifyCursorPosition(String, int)
verifyNotCursorPosition(String, int)

[Ronald Mathies]

Nice list, especially on verifyXXX and assertXXX methods i miss really
a lot.. at first i started to focus on everything that had to do with
Ajax calls and JavaScript alert/confirm/prompt dialogs because these
were completely not supported and i needed those. But this is indeed a
very nice list. I will keep my eyes on this list since a lot of these
are also onces that i use.

I also got the idea that CubicTest has no support for verifyXXX
methods at all.