-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[REUSE] Add service badges #6330
Conversation
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks for having a look at this
label: 'reuse', | ||
message: 'compliant', | ||
color: 'green', | ||
}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is looking great now. Only one final thing to address and we are done:
In the service tests the reason we run integration tests against live APIs is because we use so many external services, we want tests that fail if the upstream API goes away or makes some change that we need to respond to. We run them all once a day. We will never notice this stuff otherwise. So for this reason we usually want to accept a range of valid values in the live tests. i.e: if github.com/fsfe/reuse-tool
becomes non-compliant at some point in futre, it doesn't mean this code is broken - it just means something in this project we are using for testing changed.
Becuase the input values and output values are the same, lets pull out
const isReuseCompliance = Joi.string()
.valid('compliant', 'non-compliant', 'checking', 'unregistered')
.required()
into reuse-compliance-helper.js
and then use it in the schema:
const responseSchema = Joi.object({
status: isReuseCompliance,
}).required()
and to validate the response in the integration test:
t.create('valid repo')
.get('/github.com/fsfe/reuse-tool.json')
.expectBadge({
label: 'reuse',
message: isReuseCompliance,
})
and then you could either add another mocked service test for the valid case, or you could just write a small unit test for the helper function in a reuse-compliance-helper.spec.js
instead of doing it with mocked HTTP calls in the service tests. I'll leave it with you...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah! That is a nice observation! I'll make these changes.
… breakage in upstream API
Thanks for your first contribution 👍 |
This PR fixes issue #4365.