Test a low-code application
Titto Thommy
Regional Practice Head | Digital Integration & Process Automation | Technology enthusiast
Few months back, during a workshop about quality improvement of a?low-code application, there was an interesting discussion about unit tests that emerged.
What does “unit test” mean for a low-code application?
Traditional application development for unit tests dictate “Do this, do only this, if a test does this - it is not a unit test”. However, the principles that govern low-code application development such as model-driven design, automatic code generation, rapid application development requires us to look into new ways to “unit test”.
Remember from the?unit test factory?“Dogma is inflexible. Testing needs flexibility. Dogma kills creativity. Testing needs creativity.”
After the workshop was completed, a set of recommendations followed. One of them was to improve “test coverage”. The management team took note of the metrics to focus and added them as a part of governance.
As the saying goes “what gets measured, gets managed”, the same happened. Metrics started improving, was it a time for celebration?
What if?Goodhart’s law?has played a part? Link to a funny video.
High test coverage may not mean much, because engineers can game it.
领英推荐
Having an objective measure for tests is not bad, but it does not tell how well tested the software truly is. Doing a subjective measurement on top of objective measures may take time, but it does provide advantages.
Metrics that show bad results are useful, because it allows introspection and can open up interesting facets of the build.
For example — what is the best time to write tests?, are the tests slowing the deployment pipeline?, are we using right tools for tests?
Enabling the build team with better engineering practices is absolute key.
The Way of Testivus
“If you write code, write tests. Don’t get stuck on unit testing dogma. Embrace unit testing karma. Think of code and test as one. The test is more important than the unit. The best time to test is when the code is fresh. Tests not run waste away. An imperfect test today is better than a perfect test someday. An ugly test is better than no test. Sometimes, the test justifies the means. Only fools use no tools. Good tests fail.”
Chief and Lead Software Architect
2 年I'd argue that there is probably an api available on a low code platform which could be used to test flow processing. It would speed up the tests, as GUI tests are slow and expensive. The definition of a unit is indeed debatable for low-code. I'm still struggling in pega to figure out what their unit tests actually mean. Decision table; check. Flow; not so much. Case type; not at all. But still they all need 'unit tests' to get the guardrails up. And yes, some organizations manage the guardrail score ?? I prefer to check the code quality manually and determine if a test is required. Or just use App studio, then pega sets a property (pzIsAutoGenerated) on the rule to skip the 'need unit test'-guardrail.