Hi fellow testers!
I just published my new blog post titled “Dynamic Tests in Cypress: To Loop or Not To Loop.” Although it’s used Cypress in the example, it does apply to any other test framework.
It explores a use case where creating dynamic tests with loops helps produce cleaner test code, making it much easier to maintain and modify in the future.
This is how the article starts:
“It’s interesting how divided the automation world is about the use of loops when implementing tests. Some prefer to put the direct assertions in the test, even if it means repeating the same code again and again with just changes to the asserted data. They believe this approach is clearer. Others are definitely against duplicating code and are firm proponents of the DRY (Don’t Repeat Yourself) principle to the fullest extent […]”
I believe this approach is usually referred to as Data Driven Testing? I have some scripts that started as simple DDT but unfortunately have needed to adopt If statements as well… due to business logic changes.
If I was writing the test case now I would be tempted to instead write multiple scripts to test each flow, rather than a single complex script. Readability versus DRY.
Thank you very much @danuk for your feedback!
I understand your question about the title. The word “dynamic” could be quite generic and can vary in meaning based on the framework or even the person.
I agree that dynamic testing, DDT, among many others, may not be suitable for many cases, so each QA engineer will need to decide what is the best approach for their use case and organization.
I hope this helps to understand the context of the article’s title within the Cypress environment.
Once again, thank you for your comments. It’s discussions like these that make the world of testing truly fascinating!
Deffo agree, there are good cases for repetitive code in test suites, but also good cases for DDT , the problem with DDT used badly is that if you dont use a DDT framework, then you can end up missing some curious externalities in the service under test which might be irrelevant, or might be bugs. For example:
If I test that my account is valid, and that, in some ways changes the service internal state such that the ip address is no longer valid for that account, but if I had executed the ip address check first it might have been a valid address, then I might be failing to test a change in the interface contract. DDT framework think tries to help you by giving you tooling randomising or reversing test execution order, to find these bug classes, which once again comes down to be a really good reason to steer clear of writing tests that are really just flattened hard-coded loops. More often than we prefer to be comfortable with, we do need both approaches.
Indeed, both approaches are needed, and each of them have their own use cases.
The problem arise when a tester does not consider all the options and it’s strong hard minded in one way VS the other.
That’s also why we have not been replaced by AI (at least yet!). But that’s a subject for a different day and a different post
