3 ms·
I am too stuck in single thread front end integration tests to be able to relate. Are you actually talking about testing full stack or just some backend tech. W
by pastage 4y ago
I am too stuck in single thread front end integration tests to be able to relate. Are you actually talking about testing full stack or just some backend tech. We almost never have problems with our cloud testing, it is expensive. We need it to have some control over the front end work, benefit is that running the back end stuff is trivial and fast.
- pmarreck 4y agoI have a design bias- I pretty much refuse to build anything for the front end that is not easily testable without using a headless browser as part of my test suite. Headless browser driving adds so much more resource consumption and time to the test suite over time that it defeats the entire purpose of a test suite, which is to (as quickly as possible) assess if any logic in the app has begun violating expectations, so you can proceed with building the next thing quickly without backpedaling and without waiting. I completely understand that individual browsers may have this or that problem or idiosyncrasy and that may need to be tested but I'd put that in QA, not your official standard app test suite. At the most I'd test whether endpoints actually spit out HTML, CSS etc. but not actually check the rendering step. I do have a JS suite as part of my full test that uses jsdom to check DOM manipulation but it is only because it is not resource-intensive and runs fast.