Underlying System Flexibility of API Testing Systems

Your testing sandbox can be flexible or immutable. I have a preference for designing testing systems that are flexible. Data that is generated via the testing process, can be modified through the testing process. Everything flows the same as a live system from beginning to end. There are developers who would disagree with this approach, such as we’re giving the testers too much control that can allow testers to generate cases we didn’t expect, which can cause some amount of embarrassment. Another argument is that with fixed data, we don’t have to worry about as much, since we pretty much control the entire flow. While the counter-arguments have a legitimate point, I would argue that their limitations defeat the purpose of a testing system.

A testing system should be a sand-box, as in implied in the term “sand-box”, testers can play around with it as much as they want. If we made the data immutable, it’s not really a sand-box, but more like buttons. If a person relying on your system have a lot of unique demands on your system, your system will not be able to handle it without changing code or system structure. In fact, you’ll need to implement a whole layer just to handle the immutable data and how to handle the response. If you were to allow the system to be flexible, and the objects mutable, or changeable, there will still be layer, but that layer will be deeply tied to existing components, which will still allow existing components to be tested. While the first case, although you can still have existing components tested, such testing is pointless, since you’re forcing a set response to a set data set each time.

Flexible testing systems allow you to fulfill the demands of any tester easily, since they’re pretty much testing how their system interacts with your system, and it closely┬ámimic┬ánormal behavior. Not only that, but it also allows testers to test your system for flaws, helping point out flaws in your system before the flaw does any major damage. In an immutable system, we don’t have to worry about edge cases we didn’t account for. Which can be great, but unfortunately, a flexible system can handle the tester’s system that was design to deal with immutable or mutable data. In an immutable system, if the tester wants mutable data, we will pretty much junk the existing system and create another one. Turning a flexible system immutable is easy, turning an immutable system into a flexible system is hard. Much like procedural code versus object-oriented code, procedural code is pretty rigid, but object-oriented code is pretty flexible. “Be water, my friends.”

Leave a Reply