2 ms·
All of those things are testable. It’s data in, data out. On the frontend, not so much. You can structure your code in a way that allows for intermediate repres
by dgb23 5y ago
All of those things are testable. It’s data in, data out. On the frontend, not so much. You can structure your code in a way that allows for intermediate representations, which are more testable. But past that? Things need to look right, behave in a helpful way. You can’t assess that from within the code. At least not yet.
- eska 5y agoSo you think testing distributed systems is easier than behavior among different web browsers? Are you up for hire? /s
- dgb23 5y agoClever, but that's completely missing the point. For one I didn't mention "behavior among different web browsers". I think that's a red-herring in this discussion. What is hard about UI front-ends is not that, nor is it unique to it. It is the fact that you are providing something that's consumed by humans directly. Most of the heuristics surrounding that are fuzzy at best. It is an open system on top of that, because humans are wildly different in their perception of and ability to interact with computers. I also didn't say "testing distributed systems is easier" than that. It's a completely different game. Contrast the language/jargon/papers/practices surrounding the two: - Fault tolerance, CAP, ACID, replication etc. - accessibility, affordances, interaction, perceived performance etc. Which one of those you think lends itself more to test automation and engineering principles? Whether you find one or the other easier might depend much more on how well you do and want to understand this difference and how well you apply that knowledge.