Hi Experts,
I know this’ more of an automation question, rather than a Katalon specific question
Need an advice reg. how to automate this scenario
I have a weird business reqmt. that goes something like this →
Create an Employee in the system by entering Firstname, Lastname, DOB, DOJ, Benefit plans, etc.
Click on Submit
Employee is created successfully
Now the thing is, for e.g., if I had entered first name = Anand, and Last name = Kumar during employee creation, then system will not allow me to create another new employee with the same first and last name
However, it allows me to create another new employee with first name = ANAND1, and last name = KUMAR1, etc., like that, but not with ANAND & KUMAR
And again, if an employee is created with first & last name = ANAND1 and KUMAR1, then again it will not allow me to create with ANAND1 and KUMAR1 as the first & Last names respectively
How to overcome this situation?
I know every time I have to update the datasheet [which means that a manual intervention is required], or else, I need to request the DevOps engineer to void the employee creation from the back-end
Just read it through. You do not have to type and run the sample codes in Java; although I would love to.
Let me quote a phrase from this essay:
Now that we have implemented two test cases we notice some code duplication for setting-up the tests. It would be nice to reuse some of this test set-up code. In other words, we would like to have a common fixture for running the tests. With JUnit you can do so by storing the fixture’s objects in instance variables of your TestCase class and initialize them by overridding the setUp method. The symmetric operation to setUp is tearDown which you can override to clean up the test fixture at the end of a test. Each test runs in its own fixture and JUnit calls setUp and tearDown for each test so that there can be no side effects among test runs.
Here you should learn several terms commonly used in the software testing: “fixture”, “set-up” and “tearDown”. — This essay was the origin of these terms, you know?
You need to implement “set-up” and “tearDown” to manage the “fixture” so that your tests can run repeatedly successful. You want to initialize the target system as “set-Up”; or you want to clean-up the target system as “tearDown”. You need to implement these yourself. No AI would help you.
How to?
Katalon Studio provides the following framework. I believe, Katalon learned JUnit when they designed the product originally.
You can create an Employee programatically. Then, can you remove the newly added Employee programatically as well?
In the set-up or tearDown, your test should check if the Employee is there in the system. And if there it is, your test should remove it. By doing such cleanup, your test will be able to repeat creating the Employee next time.
If your target system does not allow you to remove the added Employee, then you should talk to the developer and ask them to change the target system so that it lets you remove the Employee programatically in order to bring the target system back to the initial state.
It doesn’t sound like an automation question, it sounds like a testing question. Before you automate something you need to understand the logic or the requirements and it sounds like initial testing hasn’t taken place. If you want to automate a test then it would help to have access to the database, otherwise you will struggle to understand the state of the system eg is this my first John Smith in the system or actually the fifth. In reality, could this simply be a unit test rather than a UI-based test script? Your dev will hopefully have already covered this and you may be duplicating effort
@anandkumar.venkatara : There are many use cases where in we can create duplicate entities like the one you have explained. In such cases, you can either use the approach @Monty_Bagati has explained (if the fields accept only alphabetic characters) or append the current date time stamp with milliseconds to the fields while creating the entities which cannot be duplicated.
This kind of constraint pops up a lot, and it’s definitely annoying when tests depend on “unique forever” data. Most teams I’ve seen get around it by auto-generating names with timestamps or random suffixes at runtime so the script stays hands-off.
Hey, I’ve run into similar scenarios before, and it’s definitely tricky when the system enforces uniqueness like that. A couple of approaches you could consider:
Dynamic data generation: Instead of manually updating the datasheet every time, you can generate unique first/last names programmatically. For example, append a timestamp or a random number to the names (ANAND_20260604 or KUMAR_458). This way, each test run always uses unique data without manual intervention. Most test frameworks, including Katalon, let you do this easily in your test scripts before sending the data to the system.
Data cleanup scripts: Some teams create a pre-test or post-test routine that either deletes or deactivates test entries. If DevOps can give you a lightweight API or a script to remove test employees, you could integrate that into your automation flow so you’re not manually asking them every time.
Use a “data pool” approach: Maintain a small dataset of names with flags indicating whether they’ve been used in a previous test. The script picks an unused one and marks it as used. This is basically like a smarter datasheet that doesn’t need constant manual updates.
Honestly, for strict uniqueness constraints, generating dynamic names on the fly is usually the easiest and most scalable approach. Saves a ton of headache compared to manual datasheet updates.
A common approach is to generate unique test data at runtime instead of storing fixed names in your data file. For example, append a timestamp, a random number, or a UUID to the first and last name (Anand_20260730_1015, Kumar_4821). That way every test run creates a unique employee without any manual updates.
If your application supports it, an even better solution is to call an API or database cleanup step after the test to remove the test employee, so the environment stays clean. But if that’s not available, dynamically generating unique names is usually the simplest and most reliable solution, and it keeps your tests independent of previous executions.
