You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -69,47 +69,132 @@ The recommended solution is to **modularize your resources**:
69
69
70
70
This modular approach not only eliminates issues like circular dependencies and performance bottlenecks but also enhances maintainability and clarity. It ensures that suite settings clearly document which components are required for each test suite.
71
71
72
+
### Example
73
+
74
+
A well-organized Robot Framework project might have a structure like this:
75
+
76
+
```
77
+
project/
78
+
├── lib/
79
+
│ └───UserData.py
80
+
├── resources/
81
+
│ ├── api/
82
+
│ │ ├── authentication.resource # API auth keywords
83
+
│ │ ├── customers.resource # Customer API endpoints
│ │ └── common_elements.resource # Shared UI elements
92
+
│ └── common/
93
+
│ ├── test_data.resource # Test data generation
94
+
│ └── utilities.resource # General helper keywords
95
+
└── tests/
96
+
├── api/
97
+
│ └── customer_api_tests.robot # Imports only api/customers.resource
98
+
├── api/
99
+
└── business/
100
+
└── contracts.robot # Imports only ui/login_page.resource
101
+
└── ui_tests/
102
+
└── login_tests.robot # Imports only ui/login_page.resource
103
+
```
104
+
105
+
In this structure, each test file imports only the specific resources it needs, avoiding a global import file. If you put the `resources` folder to your python path (this is the default for RobotCode)
106
+
107
+
Your settings section in a resource file for functional keywords, can be look like this:
108
+
109
+
```robot
110
+
*** Settings ***
111
+
# In login_tests.robot
112
+
Resource ui/login.resource
113
+
Resource ui/customers.resource
114
+
Resource common/test_data.resource
115
+
116
+
```
117
+
118
+
and if you have a suite for functional tests, like this:
119
+
120
+
```robot
121
+
*** Settings ***
122
+
# In contracts.robot
123
+
Resource functional/users.resource
124
+
Resource functional/customers.resource
125
+
Resource common/test_data.resource
126
+
127
+
```
128
+
129
+
### Migration Guide: From Global to Modular Structure
130
+
131
+
If you have an existing project with a large global resource file, consider this incremental approach:
132
+
133
+
1.**Analyze usage patterns**:
134
+
- Identify which keywords/variables are actually used in each test suite
135
+
- Look for natural functional groupings (UI, API, data generation, etc.)
136
+
137
+
2.**Create specialized resource files**:
138
+
- Start with one functional area (e.g., login functionality)
139
+
- Extract relevant keywords into a new `login.resource` file
140
+
- Maintain the original global file temporarily
141
+
142
+
3.**Gradual transition**:
143
+
- Update one test suite at a time to use the specific resource
144
+
- Keep the global import during transition for backward compatibility
145
+
- Run tests after each change to verify functionality
146
+
147
+
4.**Progressive cleanup**:
148
+
- Once all suites using specific functionality import the correct resource file
149
+
- Remove those keywords from the global file
150
+
- Eventually phase out the global file completely
151
+
152
+
For keywords that are genuinely used everywhere, consider keeping a minimal `common.resource` file, but ensure it only contains truly global utilities.
153
+
154
+
72
155
## When Restructuring Isn’t Possible
73
156
74
157
If restructuring your project isn’t an option, you can mitigate potential issues by managing warnings from your development environment. For example, you can suppress warnings related to circular dependencies and redundant imports on a per-file basis or globally.
75
158
76
-
-**Suppress Warnings in Specific Files:**
77
-
Use directives to disable warnings for circular dependencies and already-imported resources on a per-file basis.
0 commit comments