Skip to content

Testing Fullstack Apps

kimschles edited this page Sep 21, 2018 · 1 revision

I need advice re: testing. (edited) The diversity app uses Mongo, Node, Express and React. I have a few tests written for the api and zero written for the front end. I don’t want perfect to be the enemy of the good, and I want to start writing some tests. On the backend, which api things should I prioritize? Same question with the frontend. 🙂

kylecoberly [6:11 PM] For the backend, use supertest, and test happy paths for your endpoints

kim [6:12 PM] :thumbsup::skin-tone-2: The tests I’ve already written use supertest. By happy path, do you mean that each endpoint returns what I expect it to?

kylecoberly [6:12 PM] Exactly "Thorough" testing would include negative cases (e.g. Asking for a user that doesn't exist, also called "sad paths"), and edge cases (e.g. passing a number to something that expects a string)

kim [6:14 PM] That’s for future me. 🙂

kylecoberly [6:15 PM] What's hard about it in practice is that you need to wire up a test database That uses very limited, very predictable data

kim [6:15 PM] ahh (Also, I know we’ve had this conversation many times before, but I’m finally putting some of this into practice)

kylecoberly [6:17 PM] For instance, most tables will have two records that each have the name of the field ("title2") to make them easy to debug But there's still multiple records so you can test listing The other hard thing in practice is API integrations The magic trick there is to intercept all requests with something like nock and stub the returns with something predictable That way, you verify the request got made in the right format, you skip making the actual call, and you still get whatever response you would have gotten The last hard thing in the backend is authorization (protected endpoints, etc) The two popular strategies are checking the environment in your auth code, and if process.env is "testing" or whatever, just waving everything through (easy to implement, good-not-great) The other is generating a token or a session as part of your before hook and including it with the requests (edited) For the front-end, just do e2e tests with cypress if you don't have anything already Use fixtures and routes to intercept any network traffic, just like with nock on the backend Just test the things your paths your users are likely to do Since you're stubbing the network calls, you'll end up with small, predictable amounts of data And that's better testing coverage than like 95% of apps

Clone this wiki locally