Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It only takes a minute to sign up.
Sign up to join this community
Software project are often created as modules (in separated project folders) and communicate using services and apis to communicate between modules in order to improve flexibility and scalability.
Should software test automation projects echo the structure of the application in test?
That is, would they use the services and APIs the application uses, and if they do, to what extent? Is there a recognized best practice in test automation of large, complex application?
Should an automated testing project be created complex as much as software being developed?
Probably, I would handle test-code the same as production-code. It should be as complex as it needs to be. It should be just as maintainable and understandable.
Upto what extent a software automation project use these services and modules etc techniques?
When it needs it. Similar to any software project. Simple and small projects might not need it, large code-bases probably will.
Automation is about writing code.
It therefore can (and should) be as complicated or simple as need for the purpose it is needed.
Generally a more complex application, for instance one with many workflows, a mixture of JavaScript frameworks and long and detailed forms will generally require more effort and more programming approaches, such as the use of Design Patterns.
However there is no direct relationship. It is possible to have fairly simple applications that are very hard to automate due to flakiness on the backend. Also you could have a quite complex front end , but all done with simple POST forms and no js and thus the automation is relatively easy and reliable. It just all depends on the particular situation.
In terms of modules: This depends partly on the language you choose and then on the approach that fits your circumstances best. Certainly in some cases modules and methods and procedures and classes can be used to structure your code.
Often the need and desire to use modules, design patterns and other abstractions is that the code has got too complex as is and needs to be simplified. This is what should drive the desire to use programming constructs, not "application code is complex"
Should software test automation projects echo the structure of the application in test?
If "Echo" means to follow the same structure as the project from a code perspective (e.g. have package structure matching the application code) then no, not necessarily. If "Echo" means to model the application effectively - then yes, that can be very helpful.
For example, you might have workflow, usecase, or connector classes. For instance, if you have an application that writes reports and has a DB, you may have a ApplicationConnector class, a ReportConnector class, and a DatabaseConnector class. ApplicationConnector might have methods like generateReport(), which in turn invokes the application. The complexity of it is hidden away so in your test methods/steps you simply have applicationConnector.generateReport() making things very simple, readable, maintainable.
That is, would they use the services and APIs the application uses, and if they do, to what extent?
Generally no, it's best to mock these if required. i.e. have a mock application with returns some standard response. This way you're not dependent on 3rd party behaviour and can also force some fail conditions like a timeout - which you couldn't force a 3rd party to do. (e.g. "Hey accuweather, if I send a request with test_001 will you guys wait 30 seconds to give a response?" - not feasable).
Is there a recognized best practice in test automation of large, complex application?
Break it down, try testing component by component for starters. Start with the smallest easiest flow and build things up from there. Mock whatever parts you can. Model the application ecosystem. Use objects in your tests effectively, use patterns when it helps e.g. builder type pattern to build up a REST Request body. Keep the code as simple as possible. Keep in mind that less experience folks may work on it (manual testers transitioning to automation) so you want it easy for them to pick up and hard for them to introduce garbage code.
Any sufficiently supported and maintained testing project or framework, begins to take on the behavior of the application under test, unless the people adding tests to the framework take steps to keep it under control. One way to avoid this is by generous use of Mocks, Stubs, and in some cases Fakes. However, some people naturally feel that mocking can be overkill, it takes more steps to setup a mock, than to just verify an operation sometimes. So what you need to figure out is whether the attribute/event you are trying to cover with the Moq is not already covered by an existing test. It is not always a simple answer either. Plus, there are many tests which do redundant things. Even if you use good architecture with adequate separation of Concerns problems will continue to pop up.
Now, early on, it will feel like it makes a lot of sense for the structure of the tests to mirror the logical structure of the App. For small apps this is fine, but, when you start reaching enterprise level architecture, with multiple endpoints and services, you are going to have to break up the test suites so as to not have over coverage, and focused integration tests at the boundaries between components. Because of this, they are naturally going to be a little different (and they will vary depending on the team, company, project, and languages and frameworks being leveraged.) As long as the team can find what they need to test, to see what is tested, and can continue to communicate about what is needed, this is a far better, method.
