Mocking API & Server Behavior: Pros and Cons When Building a Stage Environment for QA Testing
Being able to carry out all sorts of test cases, error scenarios and unexpected behavior in a piece of software is the heart of QA testing. To achieve this, building a Stage environment is key to develop a high quality and robust mobile or web app.
Setting up a platform that faithfully mirrors the behavior of the API & Server in a safe and contained context can be achieved through a number of ways. In this post, we are going to explore the two most popular possible approaches:
1) Building a fully dedicated server aimed at staging QA testing
This approach is the most suitable when planning to carry out test cases, situations and possible error scenarios for a project without harming the current state of the service, in case the product is already in Production stage and has a number of active users. It also allows for fully and safely creating any desired API & Server behavior and thus making all necessary modifications without affecting Production environment’s sensible data.
After having developed all the necessary fixes in both the API & Server, everything can be deployed to Production stage successfully.
Pros:
- Allows for Production-like test cases and error scenarios
- Mirror end user app/service real behavior
- Fixes are directly and smoothly deployed to Production without unexpected bugs
- Real Production data can be replicated to test with real cases
- Easy to keep Production environment updated
Cons:
- Hosting the Stage environment in a dedicated server could represent added expenses to the project. Keep in mind that low fee servers can be found on the market
Observations:
- Instead of going for a dedicated server to host the Stage environment, there is also the possibility to use the same one for Production by allocating and sharing resources. This would allow for realistic server performance testing
- In case the project is on a tight budget, hiring a lower-end server to host the Stage environment could still do the trick and be useful for the development phase of the software. Unfortunately, in this case, latency and response times cannot be tested in a final user experience context
See also: Race Conditions Solution for Rails Uniqueness Validations
2) Tools to emulate API & Server interaction
Tools such as Apiary are best suited for projects that are simple in their internal architecture and in the first stages of development. This particular tool allows the user to test a developing API against an emulated server. All behaviors and possible error scenarios must be detailed within the tool and manually programmed.
Pros:
- A free account is sufficient to provide all the necessary services for a starting or developing project
- Software Engineers can have a detailed review of their API since it has to be adapted to Apiary’s model in the web app tool
- With a small or low budget project, these tools are ideal to cope with all of the necessary requirements for developing the API
Cons:
- If the project already has a developed API in Production, it has to be completely adapted and rewritten to fit the format and syntax of these sort of tools
- Test cases and possible error scenarios are carried out in an environment far from being end-user-like on a real allocated server
- Every API response and possible server behavior must be coded manually within the app’s interface
- For medium to large projects, these tools require fully dedicated Software Engineers to adapt the current API & Server Environmental characteristics, keep them fixed and updated constantly to match desired test cases, error scenarios and newly added/developed functionalities of the product
See also: ViewModel injection in ViewControllers with Storyboards
Conclusion
Depending on the complexity of the project, the developer will choose to go for either of these two options. Tools like Apiary for smaller projects are ideal and they can provide a good context to document all necessary information about the development of API. On the other hand jumping directly to dedicated or shared servers for medium to large projects is most suitable to ensure a fully tested and high-quality product.
Building a fully dedicated server for a Stage environment is not only faster to develop from the base up — since it’s almost identical to a Production environment, but it also provides for real end-user-like experiences when carrying out test cases, error scenarios and other unexpected behavior in this backend instance of the service.
As a final note, Software Engineers should keep in mind that all software demos for testing should point to the Stage server with all its respective endpoints as to ensure correct behavior.
Now the choice is yours!
Post by Marco Antonio Martín, Quality Assurance Analyst at Wolox,
(marco.martin@wolox.com.ar)
