Data validation methods

The following examples describe methods used to validate data when writing UI tests.

(sim'assertText <Expected Text>)

Use the (sim'assertText <Expected Text>) command in your UI tests to validate the contents of a data table or navigator. The (sim'assertText <Expected Text>) command uses the path provided by the (sim'use …)command that the Recorder can retrieve, and then validates that the text shown matches the actual text.

If <Expected Text> = <Actual Text>, the Scheme console returns the reference to the application as shown below:

 ;#<nexj.core.testing.ui.application.AFLApplication@30501282>

Otherwise, an error appears indicating a discrepancy between the actual and expected text:

 ;Error: Expected <Contact>, got <Contacts>.

Example

Executed code:

(sim'use "navigator/1")
(sim'assertText "Contacts")

Returned value (assuming no errors):

; 
#<nexj.core.testing.ui.application.AFLApplication@30501282>

;
#<nexj.core.testing.ui.application.AFLApplication@30501282>

UI:

(assert-equal <expected> <actual>)

This method of validating data uses (assert-equal <expected> <actual>) where expected is the text you are anticipating and actual is the pathValue of the expected text, to compare the two parameters given and ensures that they are the same.

The pathValue can be determined using a (sim'get ...) command. A (sim'get <pathValue>)command can be run after a (sim’use <element>)command, returning a specific value for the path object. The(sim'get …) function does NOT validate data. It simply returns a value for the object you have used.

If PathValue exists and is not null, the Scheme console returns a response similar to the following:

; "This is the return value"

Otherwise, the Scheme console returns:

; ()

To find the PathValue, invoke the developer tools > Console tab (clear console) and enter the following (replacing the <path> as required):

var ui = define.find("nexj/ui")
var view = ui.get(<path>)
view

The object is returned. From here, navigate the path to find a specific item. As an example, the textPreviewNotesNoHTML parameter would be retrieved as follows.

In Chrome console:

var ui = define.find("nexj/ui")
var view = ui.get ("workspaces/Contacts/p0/tabPersonJournal/refPersonJournalActivities/ref/gridActs/0")
view

By expanding the view, we can see the textPreviewNotesNoHTML path is found at _detail_.fields.0._value_.object_.textPreviewNotesNoHTML

In Scheme console:

sim'use "workspaces/Contacts/p0/tabPersonJournal/refPersonJournalActivities/ref/gridActs/0")
(sim'get "_detail_.fields.0._value_.object_.textPreviewNotesNotHTML")

Returns values:

; #<nexj.core.testing.ui.application.AFLApplication@30501282>
; "Created for Kristine Abrams on 2018-05-08."

Chrome developer tools:

NexJ UI:

In the case of (assert-equal <expected> <actual>), validate that the expected text is equal to the text given by the (sim'get PathValue) command.

The (assert-equal <expected> <actual>) command is used for UI tests in the form of (assert-equal <expected> (sim'get PathValue))

Continuing with the previous example:

Code being executed:

(sim'use "workspaces/Contacts/p0/tabPersonJournal/refPersonJournalActivities/ref/gridActs/0")
(assert-equal "Created for Kristine Abrams on 2018-05-08." ( app'get" _detail._fields.0._value._object.textPreviewNotesNoHTML"))

Return values (assuming no error):

; #<nexj.core.testing.ui.application.AFLApplication@30501282>

; ()

(sim'assertValue <PathValue> <Expected>)

Instead of using the (assert-equal <Expected> (sim'get PathValue)) command to validate data, a preferable option is to use (sim'assertValue <PathValue> <Expected>)

These two methods of validation are not equal to each other. The differences will be explained later. 

Continuing with the previous example:

Code being executed:

(sim'use "workspaces/Contacts/p0/tabPersonJournal/refPersonJournalActivities/ref/gridActs/0")
(sim'assertValue "_detail._fields.0._value._object.textPreviewNotesNoHTML" "Created for Kristine Abrams on 2018-05-08.")

Return values (assuming no error):

; #<nexj.core.testing.ui.application.AFLApplication@30501282>

; #<nexj.core.testing.ui.application.AFLApplication@30501282>

Negative testing using (sim’assertNotFound <Path>)

The (sim'assertNotFound <path>) command validates that a given path was not found by the automation test. This is useful for validating that no duplicates appear, or that only a certain number of results are returned by a search query.

If the specified path does not exist, the Scheme console returns:

; #<nexj.core.testing.ui.application.AFLApplication@30501282>

Otherwise, the Scheme console returns: 

; Error: Timed out after 15 seconds waiting for nexj.core.testing.ui.application.AFLApplication$2@5f6bc61b

Code being executed:

(app'use "workspaces/Contacts/refEntityNavigator/EntityList/groupLayout/tabPerson/grdEntity#cell.0.2")
(app'use "workspaces/Contacts/refEntityNavigator/EntityList/groupLayout/tabPerson/grdEntity#cell.1.2")
(app'assertNotFound "workspaces/Contacts/refEntityNavigator/EntityList/groupLayout/tabPerson/grdEntity#cell.2.2")

Return values (assuming no errors):

; #<nexj.core.testing.ui.application.AFLApplication@30501282>

; #<nexj.core.testing.ui.application.AFLApplication@30501282>

; #<nexj.core.testing.ui.application.AFLApplication@30501282>

UI:

Delaying the test until the condition becomes true

The (sim'WaitUntil (lambda () (<Condition>)) maximumWait) command is useful for delaying the test until the condition becomes true. If the condition cannot resolve to true within 15 seconds, a timeout error occurs. This command is often used when you need to wait for the model to update after performing a task, and before proceeding with the automated test. maximumWait (optional) is a custom timeout period in milliseconds (for example, 30000 = 30 seconds).

For example, use 'waitUntil after an asynchronous operation. Consider a test case for sending a batch email and how it can be automated:

1. User logs into the application and navigates to the Contacts workspace.
2. User selects five contacts to whom an email will be sent.
3. User opens the New batch email dialog and sends the email.
4. User navigates to the detail page for one of the selected contacts and expects to see an email interaction created in the Activities card on the Summary tab, and in the data table in the Activities tab.

The email interaction is not created instantly after clicking Send Email. The application will only create an email interaction for the contact after it can confirm that the email has been sent successfully. Therefore, an automated test case like this may fail if the detail page is checked prior to the application receiving confirmation that the email has been sent successfully. 

To automate a case like this, use 'waitUntil with the condition that the selected contact's detail page must be updated before attempting to check the contact's detail page for the email interaction.

The simplified automated code would look like the following:

SCHEME

(define emailTitle "[MQA-6389] Email Title")
(define entityToEmail (unittest-create-contact))

;Send a batch email to the above entity with the specified title

;Wait for email to finish sending after clicking the "Send" button in the UI
(sim'waitUntil
   (lambda ()
      (!= 0 ((Email'read () `(and (= (@ title) ,emailTitle) (= (@ entityParticipants entity) ,entityToEmail)) () () () ())'size))
   )
)

; Proceed to check the Contact's Activities for the Email interaction.

Method differences

The following table summarizes the method differences: