Unlike a monolithic application where you have a single point of test (more or less) in microservice you will have to test each service separately. I would suggest to consider the following points when you plan microservices-based app:
Test automation. There will be pretty challenging to test microservice-app manually since the number of services is usually ...
It is a difficult challenge!
Leading my example
Group refactoring mob sessions
Sharing best practices and relevant real world examples
Having quality topics as frequent topics of formal and informal conversations
Encouraging BDD as a standard practice fully integrated with product development
Encouraging TDD as a standard practice fully ...
If you think about what a method actually is (a procedure specific to that class to achieve a certain result or get a value) then I would use a single Login method.
Having a one-on-one relation between methods and individual elements is not doable for larger pages, and it will make your test methods very long.
My PageObjects usually have at least these same ...
A key area you are missing is Technical Excellence as described by the LeSS framework.
Specification by Example
Thinking about testing
Architecture & design
These might sound like development practises and some are, still I ...
One of many definitions, taken from the ISTQB glossary (v3.1):
(1) A person who provides guidance and strategic direction for a test organization and for its relationship with other disciplines. (2) A person who defines the way testing is structured for a given system, including topics such as test tools and test data management.
Isn't that what pageObjects are in essence: A description of the UI elements on a Page and how you can interact with them.
Now when writing tests you often interact with multiple elements in a certain way to achieve a workflow. Now if multiple tests use the same workflow it might make sense to move the combination of workflow-steps also into the pageObjects ...
Page objects work well in smaller sites where there is little to no re-use of fields because the coupling effect isn't significant enough to cause major issues - there will always be challenges finding a balance between readable tests, DRY, YAGNI, and SOLID.
I've found that once the application is large enough it's better to work in terms of input type ...
In general, any application developed in micro- services architecture, also has unit, integration, end to end, UI testing.
The exact role of QA depends (as in any typical monolithic application) on how deeply he/she knows internals of the system and involved upto what layer in the architecture.
One important testing one needs to perform w.r.t. micro- ...
Basically testing is testing is testing, the technicalities could be different but the overall approach is the same.
From my experience microservices architecture presents some challenges, but also a lot of opportunities.
Testing at the system and at a single module (and below) level are more or less the same as in any other system, you just need to keep ...
You're on the right track towards DRY test code (Don't Repeat Yourself).
This is how I'd refactor what you have:
Data-drive the tests - you have a series of almost identical tests here. For each type of test (login test, create user test), you create a data file - CSV or XML works. There is an example with TestNG here. For the login page I'd do something ...
Only program the actions (class methods) you really need. Apply the YAGNI principle. Don't write code you think you might need in the future, this will only add maintenance as you write more code than needed.
Make sure the tests are readable and describe the user behaviour. So in the example case you give, the user behavioural action is to login. So one ...
It sounds like the following scenario:
There are two distinct sections of code - application code and test code.
The code is separate and distinct, application vs testing, but there is one key point that joins them:
The test code is running against the application code
So you develop a test suite in the same general code base as the application because of ...
Good practices for UI test automation
Technical Excellence for clean code and TDD
Write human readable tests as documentation
Keep tests DRY with helpers for repeated steps
Use a BDD approach such as Given, When, Then
Ensure that Happy, Sad and Optional paths are tested
Use Page Data Objects for data being ...
It may sound trival but I suggest to occasionally involve all other team members in quality assurance activities, e.g. ask developers to suggest tests for someone else work. Show QA perspespective to people with different roles in the team. Show examples of how harmful 'we don't have time to automate/do note tests, we need to deliver news features' ...
The term PageObjects has become greatly over-used (including by me).
We have element locators.
Sometimes our element locators also have an action (such as click) with them.
Some element locators are at the page level but others can be considered to be at fragment, frame, workflow or domain specific grouping levels
These locators are then ...
The role is going to be two-fold:
Test UI components and systems that rely on the micro services (the UX)
Test the micro services themselves as not all of them may be testable through the UI.
For #2 we taught our QA SoapUI (the free one).
Postman is another option, offloading off your QA onto dev to write api tests (ex httpclient) is another one..
Extremely common problem and largely represents the 'state of play' at a great number of companies, especially though that have had a software offering for more than 10 years.
Moving from manual testing to automation is frequently misunderstood. The target is assumed to be 'automating the manual tests' and when there is just that understanding, chaos ...
Well, I believe there is no proper answer here. There is also a lot of details missing here which could bring the light on certain aspects of the issue. However I can see couple of possible ways here:
Another thing is that we need to have a clear problem statement. What does "maintain" mean and why would you need to "refactor" existing tests.
However I ...
If a developer, tester or architect has a need to see the difference between an environment then adding something like this seems fine. Don't add it because you can, but only because you really need it.
Personally I would make sure the URL shows which environment it is.
There may be many other opinions or ways to deal with this situation. But what I tried when I faced this are as follows:
Do not directly consider what all task needs to be done across amount of code
Choose premium functionalities + priority tests and fix those specific tests first
As few repetitive used tests/methods get fine tune with correct &...
As it seems to me, Page Objects does not introduce abstraction to the code since when you define a page object you do that for a specific element of the page. I would also not oppose Page Objects to Object Repository since basically object repositories are intended to store page objects.
When I use Page Object pattern, I can see the biggest value in ...
I use a 'decorate' like approach for Page Objects
I create an empty Page Object class
The I read a yaml file of name-locators
For each name-locator I dynamically add (like decorate) a method that will return the locator when passed the name
I can do this partly because I use Ruby which allows this.
You need to provide more details, or come up with more specific questions over time. We don't even know what type of product do you have.
In the meanwhile I can add some points from experience, some of it is from AWS but the general ideas are the same.
Cloud Services are like Lego blocks for adult engineers, you can achieve things in many way by connecting ...
If controls are used only together (it does not make sense to fill/click one but not the other), handle them in a single method. If they can be used separately, handle them in separate methods. Possibly provide reasonable defaults.
PageObjects provide services for tests. Design them in a way so writing tests is easier. Encapsulate all the info about the ...
I think Page Objects methods (e.g. functions, in your case set_username) should be actions. The main action on a login page is "Login". As the action is nearly always the same you can make it a single method. Do you really want to test the setting of the username? Possibly yes, but in this case not, you want to login and test some steps in the application.
This is what we call as pre-conditions and post-conditions of a test case.
In JUnit, every test case is marked with @Test annotation. Pre-conditions for each @Test are defined separately and marked with @Before annotation. Similarly, post-conditions of each @Test are defined separately and marked with @After annotation.
You can achieve similar isolation by ...
You want a number of levels of testing that require different sets of data setup. Unit tests, Unit Integration Tests, System Tests, System Integration Tests, etc... You really should consider each of these as separate pieces of testing that build upon each other - i.e. start with simple isolated testing that is passed before going onto more complex ...
For most applications, its state is store in the database, so, simply restarting the database and putting it in the desired state is ok.
For relational DBs, using procedures and calling a specific script which does the work described before is easy. The point is to study which tables must be deleted and which cannot, in order to have good performance.
Yes, store the test-code as close to the application code as you can.
If you develop with feature branches I would also build (or extend) the end2end tests in the same branch. The feature is not complete if it does not contain the end2end tests.
Tests are versioned with the feature, making it easier to support multiple versions.
Feature branches can run ...