3 ms·

Ghost of Christmas Future: I did some contracting work for a company with a 1.5 hour test suite that ran on every deploy, the section with mocked tests only to

Ghost of Christmas Future: I did some contracting work for a company with a 1.5 hour test suite that ran on every deploy, the section with mocked tests only took a couple of minutes — the rest were end-to-end (no mocks). The worst parts of those non-mocked tests: * They would interfere with each other, and could not be run in parallel. * They were subject to real-world variability and were not entirely deterministic. Management wouldn’t budget fixing or replacing the tests. Bugs still regularly found their way into production; arguments to pare down the tests were vigorously rejected. My takeaways: If possible, use a language with a strong type system to avoid writing as many tests as possible. Move as much application logic as you can into pure code (so it can be tested in isolation). Observe the test pyramid.

midrus 5y ago
Static typing has nothing to do with testing, or bugs. Static typing is about tooling, autocompletion and being able to follow the code. Using static typing as a way to reduce the number of tests is just terrible advice in my opinion. Also, the fact that tests interfere with each other, etc makes me think of just bad tests, not with a problem with the concept of e2e tests itself.
- aranchelk 5y ago
  In effect a sufficiently strong static type system greatly reduces the kinds of (mostly undesirable) programs you can compile and in doing so eliminates entire classes of bugs. If you can’t produce those bugs, then you don’t have to test for them. In the dynamic languages I’ve used (even the ones that don’t allow coercion) you can’t ensure the arguments passed to a function at runtime will be the correct type, so you’re usually stuck doing introspection or a try catch/except block to stop an undesirable argument type from messing up your application, and you should probably have tests to verify that. Working in languages with a type system the disallows nulls (nils, nones, etc.) you never ever have to test for null pointer exceptions, that should account for at least a few tests. Moving to dependent types, you can even start to verify the domain logic of your application. I think your argument may hold true for languages like Java, but it’s not applicable for the strong static functional stuff: Haskell, PureScript, Idris, etc.

midrus 5y ago

Static typing has nothing to do with testing, or bugs. Static typing is about tooling, autocompletion and being able to follow the code. Using static typing as a way to reduce the number of tests is just terrible advice in my opinion. Also, the fact that tests interfere with each other, etc makes me think of just bad tests, not with a problem with the concept of e2e tests itself.

aranchelk 5y ago
In effect a sufficiently strong static type system greatly reduces the kinds of (mostly undesirable) programs you can compile and in doing so eliminates entire classes of bugs. If you can’t produce those bugs, then you don’t have to test for them. In the dynamic languages I’ve used (even the ones that don’t allow coercion) you can’t ensure the arguments passed to a function at runtime will be the correct type, so you’re usually stuck doing introspection or a try catch/except block to stop an undesirable argument type from messing up your application, and you should probably have tests to verify that. Working in languages with a type system the disallows nulls (nils, nones, etc.) you never ever have to test for null pointer exceptions, that should account for at least a few tests. Moving to dependent types, you can even start to verify the domain logic of your application. I think your argument may hold true for languages like Java, but it’s not applicable for the strong static functional stuff: Haskell, PureScript, Idris, etc.