1) Selenium is a framework.
2) Custom page object based framework is... a framework.
3) No user says "Dashboard.Open" -> They click links, observe changes, and react to those changes.
What are you actually testing in your example? That there's a Grid with Rows? Does the user care if there is a Grid with Rows? No. They care that there's information/data inside of the table or grid or whatever that they can observe and/or take action based upon.
If you switch from a Grid to a Table or to a different way to display data, you're rewriting your test for no reason.
Selenium is not a framework. It's a library and\or tool which gives you an access. It's a finished thing for end user. It's a difference.
Page Object is not a framework. Looks like you are not familiar enought with architecture and design patterns in general. Page Object is a pattern. Like Factory, Repository, Specification, Wrapper and others.
It absolutelly doesn't matter how do common people name it. Today they name it with this verb and noun, tomorrow with another (if they don't have a vocabulary of the project. And in 9\10 times they don't). The only next things metters in software development and\or automation testing:
a) Easy maintenance
b) Clear and simple as much as possible expression of thought through commands. To reduce number of possible errors which will be made next developer after you. It's McConnel.
c) contineous refactoring
Page object and Dashboard.Open is 100% more easy to sopport and refactor then
a series of consecutive commands with parameters like:
selenium.Find("[name='submit']").click();
Asser.True(selenoum.Find("[div .someclass > div .someother class]").Display)
Or analogs from this shitty frameworks for e2e testing
Does the user care if there is a Grid with Rows? No.
I am amused by such youthful absolutism. Sure they care that it's a grid and rows. Becuase grid is convinient approach to display structured information. And people see a well known tool, having skills how to work with it.
If you switch from a Grid to a Table or to a different way to display data, you're rewriting your test for no reason
First. If control has changed - the test should be changed. Must be changed. Otherwise there was no need to change control. Be we did it for some reason.
Second. If the framework is made by tester like you, then 99% -may be yes.
While it would be my framwork, then only difference will be the change of the interface implementation. Like:
void OpenDetails(int number)
{
IGridTableObject grid = new Grid()
grid.CheckRow(number)
}
to
void OpenDetails(int number)
{
IGridTableObject table = new Table()
table.CheckRow()
}
And for final test it will the same:
Dashboard.Open();
Dashboard.OpenDetails(123);
which is made with 2 cliks with Resharper.
Because I don't loose the Liskov principles in code.
Generally developers are much better in code writing, system deising and so on, then test automation teams, becase we desigin system everyday for years. And my experience was to work as framework developer for automation test developers for last 3 years just because I'd liked to improve the quality, while the number of people is limited and we required own framwork. Why I judge so? Because I see how my subordinates, pure qa autmation developers, write code and design. It's like a sky and a ground.
Your reply is pretty offensive. I made no assumptions about who you were or your experience level. I'll leave it at that and get back to talking about code.
1 Whether or not Selenium is a framework, I don't care. The wikipedia entry for it says it is. Some people say it's not.
2 You specifically in your original post say "custom page object based framework" and "NUnit (or other test framework)" - that's all I was pointing out. You like your tools and others like their tools. They're just tools for accomplishing a goal. Your way is not "right" nor is mine. As long as they get the job done, who cares.
3 E2E tests ARE about the user experience and not about your code. If a user should care that data is structured in a certain way (say a table, or a data row, or some 3rd party data structure yet to come out) then test that behavior. Don't test the implementation details. If a user should be able to sort data - test that. If a user should be able to filter data - test that. If you're abstracting that behind a Page Object - great! It's one way to abstract things.
Users don't know about code. They don't know that a Dashboard object is being opened. They enter URLs and click links.
I don't care how you write tests as long as they are fast and give you the confidence that your application is working.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I couldn't disagree more.
1) Selenium is a framework.
2) Custom page object based framework is... a framework.
3) No user says "Dashboard.Open" -> They click links, observe changes, and react to those changes.
What are you actually testing in your example? That there's a Grid with Rows? Does the user care if there is a Grid with Rows? No. They care that there's information/data inside of the table or grid or whatever that they can observe and/or take action based upon.
If you switch from a Grid to a Table or to a different way to display data, you're rewriting your test for no reason.
a) Easy maintenance
b) Clear and simple as much as possible expression of thought through commands. To reduce number of possible errors which will be made next developer after you. It's McConnel.
c) contineous refactoring
Page object and Dashboard.Open is 100% more easy to sopport and refactor then
a series of consecutive commands with parameters like:
selenium.Find("[name='submit']").click();
Asser.True(selenoum.Find("[div .someclass > div .someother class]").Display)
Or analogs from this shitty frameworks for e2e testing
First. If control has changed - the test should be changed. Must be changed. Otherwise there was no need to change control. Be we did it for some reason.
Second. If the framework is made by tester like you, then 99% -may be yes.
While it would be my framwork, then only difference will be the change of the interface implementation. Like:
void OpenDetails(int number)
{
IGridTableObject grid = new Grid()
grid.CheckRow(number)
}
to
void OpenDetails(int number)
{
IGridTableObject table = new Table()
table.CheckRow()
}
And for final test it will the same:
Dashboard.Open();
Dashboard.OpenDetails(123);
which is made with 2 cliks with Resharper.
Because I don't loose the Liskov principles in code.
Generally developers are much better in code writing, system deising and so on, then test automation teams, becase we desigin system everyday for years. And my experience was to work as framework developer for automation test developers for last 3 years just because I'd liked to improve the quality, while the number of people is limited and we required own framwork. Why I judge so? Because I see how my subordinates, pure qa autmation developers, write code and design. It's like a sky and a ground.
Your reply is pretty offensive. I made no assumptions about who you were or your experience level. I'll leave it at that and get back to talking about code.
1 Whether or not Selenium is a framework, I don't care. The wikipedia entry for it says it is. Some people say it's not.
2 You specifically in your original post say "custom page object based framework" and "NUnit (or other test framework)" - that's all I was pointing out. You like your tools and others like their tools. They're just tools for accomplishing a goal. Your way is not "right" nor is mine. As long as they get the job done, who cares.
3 E2E tests ARE about the user experience and not about your code. If a user should care that data is structured in a certain way (say a table, or a data row, or some 3rd party data structure yet to come out) then test that behavior. Don't test the implementation details. If a user should be able to sort data - test that. If a user should be able to filter data - test that. If you're abstracting that behind a Page Object - great! It's one way to abstract things.
Users don't know about code. They don't know that a Dashboard object is being opened. They enter URLs and click links.
I don't care how you write tests as long as they are fast and give you the confidence that your application is working.