The releases are independent from the repo contents, so we can't hardcode the expected results.
But.. we discussed having a dedicated test repo which solves it.
What I was wondering though is that it doesn't feel very nice hardcoding the 10+ asset objects. There must be a better way to handle this.
Maybe we should drop the deepEqual condition and have more loose tests.
We could have our test object like this {isStrict: true, value: 'X'} when wanting to have deep equality. For example, we know 100% which is the last commit date, so let's check against the exact value.
But for cases like top contributors, integrations, and releases, we could just provide a schema, and be fine with any response which respects it.
The tests will fail.
The releases are independent from the repo contents, so we can't hardcode the expected results.
But.. we discussed having a dedicated test repo which solves it.
What I was wondering though is that it doesn't feel very nice hardcoding the 10+ asset objects. There must be a better way to handle this.
Maybe we should drop the
deepEqualcondition and have more loose tests.We could have our test object like this
{isStrict: true, value: 'X'}when wanting to have deep equality. For example, we know 100% which is the last commit date, so let's check against the exact value.But for cases like top contributors, integrations, and releases, we could just provide a schema, and be fine with any response which respects it.
Thoughts @nazrhom @jviotti ?