Already have an account? Login
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
Scanning file for viruses.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
This file cannot be downloaded
Sorry, our virus scanner detected that this file isn't safe to download.
When I was working on Selenium, I have used below Assert categories.
I don’t use assertions, as such.
Instead, I usually write code that generates data for use in an automated assay of the product.
Then I write code that applies that data to the product. When I’m doing GUI-level work, I sometimes use a page-object design. I collect data about how the product behaves and save it. I don’t find it helpful to put a lot of asserts into that code because I’m usually working with a stable GUI for which I’m creating regression checks (thus low-level asserts would almost never fail, and all that same checking I can do on a higher level anyway). Also, asserts are testing logic, and I like to separate testing logic from logic that operates the product.
As a separate process, I write code to analyze that data and flag interesting things about it. When this takes the form of pass and fail, I call the whole process “checking.” When it takes the form of alerts and visualizations, I call it “flagging.” I like to focus on complex oracles rather than simple assertions.
One problem I have with the strategy of peppering code with asserts is that everyone who does that seems to lose track of what they are or are not checking. You have a zillion asserts… what does it amount to? By writing dedicated programs to serve as oracles, I find I can keep better track of that.
Another thing to note is that I write my own frameworks, instead of using PyTest or that sort of thing.
Always in the test cases or test steps. This places it squarely at the individual project’s requirement responsibility & enables maximum reuse, shared understanding + clarity (ways of working of where to expect the assertions) then ease of maintenance.
In the above example, designing a LoginPage POM with methods such as isIncorrectLoginMessageShown(), getTextofIncorrectLoginMessage(), isUserNameEmpty(), isSubmitDisplayed(), then a DashboardPage POM with methods such as isPageDisplayedAndLoaded(), getWelcomeText() etc. will support more projects & give them each the responsibility of deciding what is a pass or failure criteria depending upon their own requirements.