Test-Driven Development (TDD) in UiPath – Part 1
Part 1 in a Series
I’m a developer, why should I worry about testing?
As a young newbie developer, when I was given a problem, I was eager to get at my computer to start coding. I was like a Labrador Retriever after a ball has been thrown into the water. I jumped right in! Testing, on the other hand, I found boring. I thought, I’ll cross that bridge when I come to it. If there’s a problem, I’ll just fix it later.
But over time, I learned that whatever could possibly go wrong, eventually will. I soon learned to stop being astounded at the stupid things that users do. They forget to enter a crucial field, they click too fast through something, they don’t check a box. No matter how much you train them to do it right, they always, always, always make mistakes. And it’s not just users. Data imports have missing fields, or fields with the wrong data type or bad data. Something goes wrong with an attachment. The server or the internet is down, the underlying operating system changed and screwed something up, etc. etc. etc.
And sometimes the problems come after the management folks get a hold of your program and start demanding changes. I built a major learning assessment program for WebMD, that served up a quiz to users, aggregated the results from all the users and automatically created a PowerPoint presentation and Word report of all the results of the program for its sponsors. I got the programming done in about 3 weeks, but after management saw it and loved it, let’s just say I spent the next year and a half incorporating every change that they wanted. Every change required me, as the sole developer, to test the whole program again manually to make sure nothing broke. I even started recruiting colleagues to help me test. But they started to resent the time it took. Eventually, I realized that having coded, automated tests to run with each and every change would be a huge time-saver.
The earlier you find a problem, the better
Every developer can tell horror stories of problems that were not caught early, and became very expensive to fix after the program was already built. In July 2024, a glitch in a software update from CrowdStrike and Microsoft caused the biggest software outage in history, affecting hotels, airlines and corporations worldwide, and costing over $5.4 billion. The problem turned out to involve an integration issue between the two software programs talking to each other, but still it should have been thoroughly tested before the update was released. Or even better, it should have been caught during the development of the code change itself.
Software development is a series of tiny decisions and assumptions. The further you go in a project, you build upon previous decisions and assumptions. If you can catch a potential problem way, way early, and either handle it, or raise an error notifying the powers-that-be of the problem, you could save time, money and many, many headaches down the road.
What is Test-Driven Development?
In UiPath, often a workflow is built in UiPath and THEN one or more Test Cases are built to run against it. Test-Driven Development turns that order on its head. In TDD, the developer builds the Test Cases FIRST, watches them fail, and THEN writes the code to make the tests pass.
Developers, after all, are closest to the code and know what could go wrong at every step. Bad input, server problems, etc. They can anticipate problems that people further up the chain can’t even imagine or can’t simulate.
Back when I worked with Javascript, I learned about TDD, and I grew to love it. Creating Test Cases before I start to code forces me to think through and imagine as many potential problems as I can, gives my code better structure and error handling, and gives me an easy place to add other cases that I may think of as I go.
TDD at the Unit Level
Unit Testing is defined as testing a particular piece of code independent of other pieces of code. This is the first and most granular line of defense, where finding problems early reaps the most benefits. In UiPath, Unit Testing is done at the workflow level.
In the next post, we will walk through coding a simple UiPath workflow using TDD. Starting with how to set up and organize the structure, creating data-driven test cases, running the tests and then coding and refactoring the code.