Chatting w/ Next.js Team Lead - Tim Neutkens

just keep it super informal i'm not gonna do like big there's no sponsors or introductions or anything uh for sure so you mentioned that you have like a testing suite or some some dev tools uh in-house that can replicate dev environments hot modular reloading like the whole thing and so yeah you're surprised when some sort of new dev bug comes up um how much of that can you talk about what's

what sort of black magic is that you got running yeah so uh overall so this is talking about uh like we were talking about the the next code base so the next year's uh framework uh that i elite um that my team works on and uh premiums ever since the beginning uh we've been all in on uh end-to-end integration testing like we have very few unit tests everything is integration tests okay so the reason behind that is we

um basically want to ensure that what you as an end user use is what we are testing against right right um because like otherwise you get like all these kind of like strange like hkc bugs that uh are really hard to replicate and like unit testing and all that um so that's why we went all in on integration testing um so the way that this works is like in the next code base itself and

it's it's all open source by the way there there's no uh specific like closed source uh software there or anything um we we basically have a test suite driven by jest that is like has some utilities to basically boot up the next cs development server or the production build or the production server um using the command line so just like process spam basically um and it spawns different instances of next um on different ports okay and then

uh the different versions too uh no different versions so only the latest um the current code base that you're on basically um but we also run it in like various different configurations like every single uh next config option that you have oh yeah like various different configurations like uh service rendering static generation

like everything combined in one app all that um but like basically where that starts is we we run our tests on top of selenium the browser testing uh framework um and we use the library called wd which is web driver uh sheridan in this to the two characters um this is npm library that you can install to basically talk to um chrome driver and other selenium powered browsers right so uh we test against firefox safari

um internet explorer 11. um which is where like most of the like oh you wrote new right modern code it breaks in ie11 like the kind of stuff um they used to come up very often so we eventually added in testing for ie11 as well um whose job was that was that yours i mean uh someone on my team did it but it was very easy to do because like we already had the infrastructure there was selenium

so it was only like adding this configuration for browser stack yeah and then like the test runs on ryzer stack uh through like the exact same framework we already had um okay which is really neat because like we started out with just uh chrome as like the the test uh browser right um and then um basically like we do like we run the test inside of a rear browser right like inside of chrome or inside of uh