4 ms·

> The type system cannot replace all testing, but there are certainly places where it can make testing superfluous. I agree. We configure analysis to ignore bo

> The type system cannot replace all testing, but there are certainly places where it can make testing superfluous. I agree. We configure analysis to ignore boilerplate code, for example, so that doesn't count toward out coverage threshold. And in this particular example, yeah, there is an entire class of tests that no longer need to be written; the "did he really pass me an integer, or is it JSON" style assertions. Typescript (and strong typing in general) is super helpful for eliminating that category of test. > However, and this is a sincere question: do you work on web frontends? When I'm forced to. I'd say my work in 80% backend, 20% frontend, though that ratio changes based on what stories we pick up for the week. But we use TDD for our frontend, too. I have selenium tests that bring up the backend, launch the web UI, and run through the required functionality. It's a very different mentality, and we don't check things like CSS layouts at this level, but the general "the user clicks this button and gets this result" are all verified automatically.

eyelidlessness 7y ago
> When I'm forced to. I hear you. And I think this may account for some of your frontend testing solutions. (Which I in now way mean to disparage.) Given a set of technologies that allow it, another way is possible, significantly easier, with a faster red-green cycle and probably a higher degree of confidence. It looks a lot like what Gary described in TFA. Given: - A good type system - A component system with single-direction data flow - A state abstraction that is testable outside of the DOM (Edit: not sure why HN won't let me make a list without empty lines but there you go) In quite a lot of cases the tests can be isolated to your state logic, and the mere presence of a component and a passing compilation is enough to ensure your frontend works. You can even, with some effort, ensure the presence with the type system. It doesn't necessarily eliminate all end to end testing scenarios, but for a lot of sites/apps it may.
- steveklabnik 7y ago
  > (Edit: not sure why HN won't let me make a list without empty lines but there you go) because hn formatting doesn't actually have a "list" concept https://news.ycombinator.com/formatdoc https://news.ycombinator.com/formatdoc
  - eyelidlessness 7y ago
    It's not so much that I want it to render as a list (e.g. like Markdown), but that I want to produce separate lines of text without an additional blank line between them.

eyelidlessness 7y ago

> When I'm forced to. I hear you. And I think this may account for some of your frontend testing solutions. (Which I in now way mean to disparage.) Given a set of technologies that allow it, another way is possible, significantly easier, with a faster red-green cycle and probably a higher degree of confidence. It looks a lot like what Gary described in TFA. Given: - A good type system - A component system with single-direction data flow - A state abstraction that is testable outside of the DOM (Edit: not sure why HN won't let me make a list without empty lines but there you go) In quite a lot of cases the tests can be isolated to your state logic, and the mere presence of a component and a passing compilation is enough to ensure your frontend works. You can even, with some effort, ensure the presence with the type system. It doesn't necessarily eliminate all end to end testing scenarios, but for a lot of sites/apps it may.

steveklabnik 7y ago
> (Edit: not sure why HN won't let me make a list without empty lines but there you go) because hn formatting doesn't actually have a "list" concept https://news.ycombinator.com/formatdoc https://news.ycombinator.com/formatdoc
- eyelidlessness 7y ago
  It's not so much that I want it to render as a list (e.g. like Markdown), but that I want to produce separate lines of text without an additional blank line between them.