[HN Gopher] We need to talk about testing
       ___________________________________________________________________
        
       We need to talk about testing
        
       Author : glenjamin
       Score  : 13 points
       Date   : 2021-07-27 08:32 UTC (14 hours ago)
        
 (HTM) web link (dannorth.net)
 (TXT) w3m dump (dannorth.net)
        
       | geofft wrote:
       | The idea that the tests of TDD are not the same thing as the
       | tests of test coverage is a great insight that I don't think I'd
       | quite realized before. In my experience, that seems in fact
       | accurate - writing a short tool that _uses_ the code you want to
       | write is a good way to break down the problem and also make sure
       | your solution actually works, but it 's different from having
       | confidence in the system.
       | 
       | On the other hand, I'm a little confused at the idea of non-
       | automated tests that provide value. If you're interested in
       | security/compliance/accessibility/etc., those seem like general
       | software quality things, but they don't seem like "tests." To me,
       | a "test" is a thing that either passes or fails, by analogy to
       | tests in education, tests in law, etc. It's definitely valuable
       | to review code for security issues or ensure that you're taking
       | accessibility into account, but unless you're asking a question
       | that can produce a yes or no, then you're not increasing
       | stakeholder confidence _through evidence_ , per the article's
       | formulation (which I agree with). If you think there's value in
       | manual testing because a human will provide you with "insights
       | and feedback," great, but if you do hallway "testing" and
       | everyone successfully completes the task but provides no
       | feedback, is that a failure? If you can't find any security bugs
       | from reading the code, does that mean there are none?
       | 
       | If you want unstructured information from humans as part of
       | inputs to your design, great (and that's a great reason to shift
       | _feedback_ left), but I think that 's a different category from
       | testing.
       | 
       | You can't automate everything but you can automate a whole lot.
       | Static analysis tools, better languages, modeling tools, etc. can
       | find or prevent security problems more reliably than a human.
       | Linters can check for accessibility issues (missing alt tags,
       | missing ARIA attributes, etc.), and you can write integration
       | tests that try to drive your entire product using only
       | accessibility APIs to make sure your workflows are covered.
       | Automated tests can look at emitted logs and metrics and make
       | sure they're emitting what you expect and not emitting what you
       | don't. And so forth.
        
       ___________________________________________________________________
       (page generated 2021-07-27 23:00 UTC)