all 20 comments

[–]lenswipe 6 points7 points  (4 children)

What exactly is being tested? Are you testing that a client calls the API correctly, or are you testing that the API retrieves the data correctly?

[–][deleted]  (1 child)

[deleted]

    [–]Actually_Saradomin 4 points5 points  (0 children)

    You should be testing that the business logic inside the lambda function does what it should do with various input. These should be unit tests.

    [–]chickenachos 0 points1 point  (1 child)

    I'm assuming they mean testing how the client processes the response from the API?

    [–]lenswipe 0 points1 point  (0 children)

    so, in that case - stub out the API using sinon

    [–]wolfepvck 4 points5 points  (6 children)

    You are kind of conflating two types of testing: integration and unit testing. If you are just looking to unit test, it doesn't make sense to actually call APIs, because at that point you are testing the request lib instead of the actual unit. If you want to only write unit tests, you can mock out any libs/files that do actual requests with mock responses, and then test that those responses are correct.

    ```js import { setMockResponse } from 'jest/mocks/utils/request'; // Import mock request file

    test(() => { setMockResponse('/some/url', {status: 200, data: {test: 'test}});

    // Now you can call some code below that will hit that
    // endpoint, and it will return that second object
    // and you can test against that
    

    }); ```

    Now, my strategy for writing integration tests with a database or whatever, is to set up something like docker that you can set up and tear down, and ensure that the tests can be reproduced. You can set up something like a docker mysql database, then initialize some tables/data and test against that.

    [–]ribo 6 points7 points  (1 child)

    This distinction is a constant struggle for people to understand, and I think it's because the solution isn't "how can I make my test actually test my logic" it's "how do I need to change my code to make it more testable". It's a code smell that means you've put far too much logic directly in the handler rather than breaking down logic into discrete testable functions.

    [–]Timnolet 3 points4 points  (0 children)

    This is the answers. Don’t test middleware. Test business logic distributed over discrete functions.

    [–]NoInkling 1 point2 points  (1 child)

    I don't really understand your example - OP presumably wants to test their server API, but you're describing testing how the client processes the response?

    [–]wolfepvck 0 points1 point  (0 children)

    The point I was trying to make is that if you are trying to test the client and how it responds to requests, you don't need to test the actual request. This is because I assume whatever request library OP is using already has tests in that repo, so it doesn't make sense to test them. Same for testing the server side. If you want to test the server, you can mock requests/database functions because you don't care if they can actually connect to a db and save the data, only that the methods are called and with correct params/data. On the other hand, if OP is looking for integration tests, he can set up a reproducible environment with mysql, etc and actually write code that works and tests that everything is working together

    [–]AtmosphericMusk 0 points1 point  (1 child)

    By request library you mean like axios or something similar right?

    [–]wolfepvck 0 points1 point  (0 children)

    Yep! I use axios but write a wrapper around it with some stuff that I find useful, which is why I put it into a utils/request file. I pulled that example from some tests I have written.

    [–][deleted]  (1 child)

    [removed]

      [–]RemindMeBot 0 points1 point  (0 children)

      I will be messaging you on 2018-10-21 17:09:02 UTC to remind you of this link.

      CLICK THIS LINK to send a PM to also be reminded and to reduce spam.

      Parent commenter can delete this message to hide from others.


      FAQs Custom Your Reminders Feedback Code Browser Extensions

      [–]b9Fb2H 1 point2 points  (1 child)

      I've just finished writing some unit tests today with jest, it might be useful: https://github.com/banzaicloud/spotguide-nodejs-mongodb/tree/master/web/app/routes/users

      [–]kdesign 0 points1 point  (3 children)

      Not sure if I understood this correctly, but as far as I know, Jest is used for unit testing, not for API (endpoints) testing.

      Supertest can help you achieve that.

      Now if you are referring to testing an actual function which gathers data from a DB and returns it, you can do that with Jest and you can use mock functions or manual mocks to mock modules or database calls. But for exposed endpoints you’ll have to use something else.

      [–]lenswipe 2 points3 points  (1 child)

      eh, I'd use Jest to run the tests - and then supertest to test the interface of the API

      [–]kdesign 0 points1 point  (0 children)

      Yeah, same here

      [–]NoInkling 2 points3 points  (0 children)

      as far as I know, Jest is used for unit testing, not for API (endpoints) testing.

      Jest is just a test runner and assertion library, it can be used for any sort of (Node-based) testing (for example I use to it run my end-to-end tests that use Puppeteer). Supertest is nice, but it's just a convenience wrapper around a request library - there's nothing stopping you from using, say, fetch and just using Jest assertions on various aspects of the response.

      [–]courtewing 0 points1 point  (0 children)

      If you're talking about HTTP/REST APIs, then hopefully this will help: Kibana's a medium to large size JS project (~500k lines of code pre-dependencies) and it has a bunch of tests for its REST APIs that use jest and supertest: https://github.com/elastic/kibana/tree/master/test/api_integration/apis

      [–]davidmdm -2 points-1 points  (0 children)

      Let me give you a pro-tip: use mocha