info:To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
---
# Resource class in GitLab QA
# Resource classes in GitLab QA
Resources are primarily created using Browser UI steps, but can also
be created via the API or the CLI.
Resources are primarily created using Browser UI steps, but can also be created via the API or the CLI.
A typical resource class is used to create a new resource that can be used in a single test. However, several tests can
end up creating the same kind of resource and use it in ways that mean it could have been
used by more than one test. Creating a new resource each time is not efficient. Therefore, we can also create reusable
resources that are created once and can then be used by many tests.
In the following section the content focuses on single-use resources, however it also applies to reusable resources.
Information specific to [reusable resources is detailed below](#reusable-resources).
## How to properly implement a resource class?
All resource classes should inherit from `Resource::Base`.
All non-reusable resource classes should inherit from `Resource::Base`.
There is only one mandatory method to implement to define a resource class.
This is the `#fabricate!` method, which is used to build the resource via the
...
...
@@ -391,6 +398,96 @@ end
In this case, the result is similar to calling `Resource::Shirt.fabricate!`.
## Reusable resources
Reusable resources are created by the first test that needs a particular kind of resource, and then any test that needs
the same kind of resource can reuse it instead of creating a new one.
The `ReusableProject` resource is an example of this class:
```ruby
moduleQA
moduleResource
classReusableProject<Project# A reusable resource inherits from the resource class that we want to be able to reuse.
prependReusable# The Reusable module mixes in some methods that help implement reuse.
definitialize
super# A ReusableProject is a Project so it should be initialized as one.
# Some Project attributes aren't valid and need to be overridden. For example, a ReusableProject keeps its name once it's created,
# so we don't add a random string to the name specified.
@add_name_uuid=false
# It has a default name, and a different name can be specified when a resource is first created. However, the same name must be
# provided any time that instance of the resource is used.
@name="reusable_project"
# Several instances of a ReusableProject can exists as long as each is identified via a unique value for `reuse_as`.
@reuse_as=:default_project
end
# All reusable resource classes must validate that an instance meets the conditions that allow reuse. For example,
# by confirming that the name specified for the instance is valid and doesn't conflict with other instances.
defvalidate_reuse_preconditions
raiseResourceReuseErrorunlessreused_name_valid?
end
end
end
end
```
Consider some examples of how a reusable resource is used:
# @return [nil] returns nil unless an error is raised
defvalidate_reuse_preconditions
unlessreused_name_unique?
raiseResourceReuseError,
"Reusable projects must have the same name. The project reused as #{reuse_as} has the name '#{name}' but it should be '#{self.class.resources[reuse_as].name}'"
end
end
# Checks if the project is being reused with the same name.
#
# @return [Boolean] true if the project's name is different from another project with the same reuse symbol (reuse_as)