Decoupling Hot API Integration Tests from External, Stateful Methods

I've been discussing with my team the concept of decoupled API integration tests, and I'd like to get Reddit's opinion on this concept, and see if anyone has done anything like this.I've been experimenting with babel-plugin-rewire, and although it itself seems to be rather stateful when used with ava's default parallel behavior (it won't be in the correct state if run in parallel), it allows me to rewrite methods, method signatures, and responses. This allows me to take conditional testing code out of source files, and keep it within just the test files. I couldn't think of a better way to do this in Babel ESNext.So, that's very fine and dandy, but there's something missing. I can mock external APIs till the cows come home, but lord willing and the creek don't rise, my notion of the mocked external APIs could be colder than a well digger's butt.The flip-side is that I've written hot integration tests before, and it's worse than playing QWOP. This is because they change the state of the systems I'm testing more often than not, and I have to wait for requests to finish, which is going to make the tests brittle if I wait too short, but will take longer if I wait longer. It's a delicate balancing act that is very time-consuming. I wouldn't recommend it, which is why API decoupling is such a welcome concept.I'm just thinking, maybe I might want to have simple, decoupled tests of some kind, similar to the testing signatures I'm supplying to the rewired methods, but unfortunately, that's very difficult in a real-world test plan that's testing real actual things. Getting to a realistic state is often very difficult... But then the other problem is that the external API might be changing often enough to cause issue.Ultimately, if I decouple the test from my own business logic, it still might simplify the equation quite a bit, I might be writing fewer tests, and I'll know if it's me or them. I'd also be running hot tests fewer times, perhaps only on PRs and CI.Anyway, I'm going to continue down this road and I'll report back, if there's enough interest. Also, I'm aware of the stereotypes around narcissist JavaScript devs who are notorious for coming up with a JS way to do something, but it's really an ancient concept that Lisp devs have been doing since the 1960s. But I might do it anyway, so I might come up with a trendy name for it, like DecAPItating your tests.I'm looking for thoughts, critique, even trendier names, better colloquialisms (preferably from the Colorado & New Mexico region), better ideas, and personal experiences.

Submitted November 21, 2016 at 10:38AM by cryptoquick