-
Notifications
You must be signed in to change notification settings - Fork 61
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
Multiple assertions in specified order #52
Comments
The F# example doesn't look very asynchronous, unless there's a whole bunch of magic going on there. It also looks like bad test design since it tests two different properties in a single test. Creation and deletion seems like it should be separate tests, but perhaps this is just a contrived example. In any case, you can just chain the promises. That's what they're for, after all. Something like this: testPromise "deleteResource" (fun () ->
getAllResources ()
|> Js.Promise.then_ (fun before ->
deleteResource resource.id
|> Js.Promise.then_(getAllResources)
|> Js.Promise.then_(fun after -> expect (before, after) |> toEqual ([resource], []) |> Js.Promise.resolve)
)
); |
You are right, those calls are synchronous. An asynchronous version would look something like this in an async computational expression:
Not sure how that could work - those are API (Integration) tests - they run against a "real" environment with a real database and everything. Unless the test creates a resource, there is nothing it can delete in order to test whether deletion works, so the deletion test would have to create the resource in any case, even if it was a separate test. Thanks for the example, I will give it a try! Chaining and nesting promises this way looks like a readability disaster though 🙃 |
I'm not a big fan of integration tests that mutate shared state since failure can be caused by executing tests in different order, failing other tests, and because it requires a lot more setup and teardown which obfuscates the actual property you're trying to test. I'd rather use a mock database that's just thrown away and rebuilt for each test. Then you can just delete a known resource, and that's that. The async computation expression will produce code that is essentially exactly like the nested promise chain I showed. You can make it a bit nicer by defining I'll close this issue now as I think it's been answered as best it can, but feel free to keep commenting if you have further questions or suggestions or whatnot :) |
Neither am I, to be honest. In this case, however, it's not really a matter of choice - the backend/API/database package is simply a black box that we don't have control over, but rather build a frontend on top of. So a mock database and similar solutions are not really applicable. I do need those tests on the frontend side, however, since it's rather common that backend changes of the API break stuff on the frontend that TypeScript is ill-equipped to handle due to the lack of runtime checks. OCaml JSON Decoders come in really handy (edit: just realized that bs-jest is your package too 😄), so that's the solution I am trying out now - might even do a writeup on the topic if it turns out a success :)
True, but the code would be "flat" - it's the "nestedness" I am concerned about. Maybe it's a matter of preference, but especially if there are more operations to perform in a sequence that depend on each other, and the number of levels of nesting grows, I find it increasingly more difficult to follow. Thanks for the links, really useful stuff! Looks like there is a suggestion to backport this syntax even before bs supports OCaml 4.08, so hopefully it won't take years :) Meanwhile, I am actually leaning towards writing such tests in TypeScript. As much as I dislike it, it might just be a better fit, given the imperative/sequential nature of those tests. Thanks again for your response! |
You need to teach those back-end guys about API-versioning and backwards-compatible API changes it seems. But yeah, I can understand the need in that case.
No, I completely agree. My point is just that it's not something that can be fixed by changing the API. The problem inherently requires language support. So for the moment a different language might be what you need. |
There exists a port of That would allow you to write
similar to
in F# |
Hehe, they know :) Since API v1 hasn't been "officially" released yet, versioning and backwards compatibility would result in too much overhead and thus were consciously omitted for now. Who knows, maybe the need for such tests is not going to be as pronounced when backwards-compatibility is respected.
Yeah, the only thing I was thinking could help in this situation would be an assertion in the middle of the test. I supposed that could help with the nesting, since I wouldn't need to carry over the Will go try out ppx_let, thanks! |
Hi. I am looking into porting some API-tests written in F# from our backend to OCaml/Bucklescript. I've read the documentation part about all tests having to return an assertion, which forces to have one and only one assertion, so I am wondering whether it's possible to achieve such an imperative testing scenario with
bs-jest
at all. So far, I have managed to make one API call and make one assertion on the result, but have no idea how I would go about chaining another API call using the ID returned by the first one and making another assertion.Here is my simple attempt with one assertion:
Here is a sample F#/xUnit test I am trying to convert:
Writing such a test with TypeScript and
async/await
is pretty much straightforward.The text was updated successfully, but these errors were encountered: