-
Notifications
You must be signed in to change notification settings - Fork 61
frontend: add additional test for api select #995
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
Conversation
fb26309
to
f9bf9cf
Compare
f9bf9cf
to
1a1e33e
Compare
function mockPromiseResolving (value) { | ||
return new Promise((resolve, reject) => { | ||
const timer = setTimeout(() => { | ||
clearTimeout(timer) | ||
resolve(value) | ||
}, 100) | ||
}) | ||
} | ||
|
||
class MockStubbing { | ||
constructor (fieldName, value) { | ||
this._fieldName = fieldName | ||
this._value = value | ||
} | ||
|
||
forFieldName (fieldName) { | ||
this._fieldName = fieldName | ||
return this | ||
} | ||
|
||
get fieldName () { | ||
return this._fieldName | ||
} | ||
|
||
get value () { | ||
return this._value | ||
} | ||
} | ||
|
||
class ApiMockState { | ||
constructor () { | ||
this._get = jest.fn() | ||
this._patch = jest.fn() | ||
} | ||
|
||
getMocks () { | ||
return { | ||
get: this._get, | ||
patch: this._patch | ||
} | ||
} | ||
|
||
get () { | ||
const apiMock = this | ||
return { | ||
thenReturn (mockStubbing) { | ||
if (!(mockStubbing instanceof MockStubbing)) { | ||
throw new Error('apiMock must be instance of MockStubbing') | ||
} | ||
if (mockStubbing.fieldName === undefined || mockStubbing.value === undefined) { | ||
throw new Error('fieldName and value must be defined') | ||
} | ||
apiMock._get.mockReturnValue({ | ||
[mockStubbing.fieldName]: mockStubbing.value, | ||
_meta: { | ||
load: Promise.resolve(mockStubbing.value) | ||
} | ||
}) | ||
} | ||
} | ||
} | ||
|
||
patch () { | ||
const apiMock = this | ||
return { | ||
thenReturn (mockStubbing) { | ||
if (!(mockStubbing instanceof MockStubbing)) { | ||
throw new Error('apiMock must be instance of MockStubbing') | ||
} | ||
if (mockStubbing.fieldName !== undefined || mockStubbing.value === undefined) { | ||
throw new Error('fieldName must be undefined and value must be defined') | ||
} | ||
apiMock._patch.mockReturnValue(mockPromiseResolving(mockStubbing.value)) | ||
} | ||
} | ||
} | ||
} | ||
|
||
export class ApiMock { | ||
static create () { | ||
return new ApiMockState() | ||
} | ||
|
||
static success (value) { | ||
return new MockStubbing(undefined, value) | ||
} | ||
} |
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.
Wow, that's a lot of code for adding just a single test. This looks like something we could integrate directly in hal-json-vuex, would you agree? I am worried that this will be hard to maintain if it's sitting here.
Is there a special reason why this is necessary here and not in the other ApiFormComponent tests?
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.
I started here and thought i don't want this massive object in the test just to mock the api.
For the next tests, my live will be easier.
It would be nice if hal-json-vuex would offer a way to mock itself in tests.
I would wait a little to look if it really helps to write shorter tests with less boilerplate, and then we can migrate it to hal-json-vuex.
I also did not check if my mocks represent the behaviour of hal-json-vuex correctly, it worked for that test.
With JUnit you normally just write the hierarchy in the test like:
const api = jest.fn()
const get = jest.fn()
api.mockReturnValue('get', get)
get.mockReturnValue
Maybe there is a reason to not write such a mocking helper, but to repeat yourself?
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.
Als temporärer Zustand finde ichs okay zum mergen. Längerfristig sollte der Test nochmals umgeschrieben werden und ApiMock.js entfernt werden, wenn hal-json-vuex das von Haus aus kann.
const timer = setTimeout(() => { | ||
clearTimeout(timer) | ||
resolve(value) | ||
}, 100) |
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.
Warum reichen 100 Millisekunden? Was garantiert uns dass wir das nicht beim nächsten Test auf 200 Millisekunden hochschrauben müssen? Könnte man auch 0 Millisekunden nehmen? In JavaScript ist ein Timeout von 0 Millisekunden ausreichend, um auf die nächste Runde des Event Loops zu warten. Vielleicht brauchts auch gar keinen Timeout?
return new Promise((resolve) => {
resolve(value)
})
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.
Ist von ApiWrapper kopiert
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.
Ja, habe ich inzwischen auch gesehen. Das sollte dann wenn möglich auch dort abgelöst werden.
No description provided.