Follow-up from "Refactor php composer specs"
The following discussion from !31726 (merged) should be addressed:
-
@rspeicher started a discussion: (+1 comment) @ggelatti Thanks for looking into this. I worry however that it's making an already-confusing spec more confusing, in pursuit of reducing repetition.
In order to understand an individual test, for example the one on line 194, I have to:
- Mentally map the
params
values used byit_behaves_like
to the table from thewhere
defintion; - Look up the shared example;
- Understand how the three parameters passed to
include_context
may modify the shared example; - Understand the conditional
token
andheaders
definitions;- Possibly looking up the definition of
build_basic_auth_header
, which is in yet another file;
- Possibly looking up the definition of
- Recognize that
user
,project
, andgroup
being defined are implicit requirements of the shared contexts;
I happened to read The Self-Contained Test this morning. In the spirit of that, I might suggest these changes:
- Separate the
anonymous
checks from the logged-in checks. They're unique -- an anonymous user always receives:unauthorized
, regardless of membership (not applicable) or token passed via header. This removes the need for theuser_role == :anonymous
check and the conditionalheaders
definitions. - Remove the
user_token
definition. With the:anonymous
tests separated from the others, we always run two tests per role: one with the correct token, one without. These can be discrete tests in thewith_them
block. An invalid token always results in:unauthorized
, regardless of other parameters, so we can reduce the number ofwhere
definitions, simplifying the file overall.
WDYT?
- Mentally map the
This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.