The moment your tests start repeating themselves is the moment to reach for user keywords and resource files. Together they turn a pile of similar tests into a tidy, maintainable suite.
Your own keywords
A user keyword is one you define yourself by combining other keywords. You give it a readable name and use it in tests exactly like a built-in keyword. With arguments, one keyword serves many cases:
*** Keywords ***
Log In As
[Arguments] ${username} ${password}
Fill Text id=username ${username}
Fill Secret id=password ${password}
Click id=login
Now a test reads as intent, Log In As standard_user secret, and the detail lives in one place. This is the heart of the keyword-driven approach, which we cover in keyword-driven testing explained.
Sharing across suites
Keywords defined inside a test file only work in that file. Move them into a resource file, an ordinary file with a .resource extension, and import it wherever you need those keywords. Every suite that imports it gets the same building blocks, so a fix in one place benefits them all. That single fact is why resource files are the backbone of a maintainable project.
The skill that matters
The judgement worth developing is where to draw the line between keywords: high enough to read as a meaningful step, low enough to reuse. Log In As is a good keyword. Click The Third Button usually is not. Getting that balance right across a real project is a large part of what a structured course teaches.
Our Robot Framework Certified Professional course covers keyword design and project structure in depth, and prepares you for the RFCP exam.
Frequently asked questions
What is a resource file?
A file with a .resource extension that holds keywords, variables and imports you want to share across suites. You make them available with the Resource setting.
What is the difference between a user keyword and a library keyword? A library keyword comes from an imported library and does low-level work. A user keyword is one you define by combining others, usually to make a readable, higher-level step.
How does this keep a suite maintainable? When the application changes, you update the keyword once rather than every test that used it. That is the main reason keyword-driven suites age well.
Next: setup and teardown, or revisit variables.