[HN Gopher] Best Practices for Testing in Java (2019)
       ___________________________________________________________________
        
       Best Practices for Testing in Java (2019)
        
       Author : moks
       Score  : 25 points
       Date   : 2020-09-01 19:49 UTC (3 hours ago)
        
 (HTM) web link (phauer.com)
 (TXT) w3m dump (phauer.com)
        
       | codeulike wrote:
       | _" Do programmers have any specific superstitions?"
       | 
       | "Yeah, but we call them best practices."_
       | 
       | (from https://twitter.com/dbgrandi/status/508329463990734848 but
       | thats probably not the original source)
        
       | r0s wrote:
       | Good stuff. I especially appreciate the entreaty to limit
       | assertions and corner cases to one test concern.
       | 
       | The only thing I didn't like was the Given When Then
       | recommendation. BDD style story language is really meant for key
       | specification examples, which can be automated in functional
       | tests, but not really appropriate for unit testing.
        
         | joshka wrote:
         | This article says GWT, but all the examples are showing AAA
         | (Arrange Act Assert). Subtle semantic difference, likely not
         | the core of the article though.
        
         | zoover2020 wrote:
         | Why not BDD style in unit tests though? Our team adopted it and
         | I really like it over triple A.
        
           | UK-Al05 wrote:
           | I don't really understand his argument against it.
        
         | noisem4ker wrote:
         | Even for unit testing, I find that a standard arrange-act-
         | assert structure is helpful.
        
       | commandlinefan wrote:
       | I'd be happy if we could just get to the point where programmers
       | wrote code that _could_ be unit tested. i.e. don 't write static
       | initializers that connect to live databases for a start.
        
         | Spivak wrote:
         | I'm kinda confused about that one. Because if the value isn't
         | coming from some external source like a db, api, file, whatever
         | then why do you even need a static initalizer? If you mean they
         | hardcoded the prod database then I'm so sorry.
        
         | eecc wrote:
         | Haven't seen anything that bad in ages, but yeah... I'd lose my
         | cool if I saw that.
         | 
         | Last bad thing I saw was - quite recently actually - some
         | business code in a request handler mutating state on a
         | controller field (which are singletons.) Lots of fun once we
         | started load testing with concurrent sessions...
        
         | exabrial wrote:
         | Dependency Injection + Mockito allows one to do that. There's a
         | whole study on writing code that's easy tested. Our rule is no
         | more than 4 layers: initiator, business logic, services, anemic
         | domain model. Initiators abstract away the inbound protocol and
         | serialize to the common model. Business logic controller handle
         | all of the branching. Services effectuate single actions.
         | Services can't call other services. And the domain model is how
         | everything talks. We all build our apps this way and it's
         | really easy to move people between projects. Not perfect but
         | works for about 85% of stuff one has to write.
        
       | bvanderveen wrote:
       | Great article. The only thing I would add is that anything other
       | than `assertEquals(expectedValue, actualValue)` is not really
       | permissible. Don't make assertions about 'portion' or 'subset' of
       | your results, make assertions about the entire value! Otherwise,
       | you're throwing away an opportunity to encode a constraint;
       | sooner or later the undefined behavior will make itself known. We
       | are writing tests to avoid that scenario in the first place, no?
        
         | joshka wrote:
         | Partial Disagreement on the phrasing of this - there are many
         | classes of assertion like
         | `assertThat(expected).containsInAnyOrder(foo,bar,baz);` that
         | would not meet this. Order often does not matter and cannot be
         | constrained. There are other things similar to this.
        
       | vemv wrote:
       | > KISS > DRY
       | 
       | I'd agree elsewhere, but not for tests. Non-DRY tests often means
       | that there's an ad-hoc similarity between a series of tests.
       | 
       | Without DRYness, as time passes, domain knowledge fades away, and
       | more maintainers touch the same test code, it becomes quite
       | likely that this similarity will be broken. Which is a perfect
       | recipe for false negatives: one fixes one test but not all other
       | tests, which might start exercising a useless code path due to
       | drift.
        
         | joshka wrote:
         | The more canonical form is DAMP rather than KISS. Descriptive
         | and Meaningful Phrases. DRY is fine in moderation in tests.
         | E.g. instead of
         | `Person.builder().withName("Alice").withAge(100).build();`
         | using `People.grandmother()` is DRY-ish, but certainly
         | something you'd see less of in production code.
        
       ___________________________________________________________________
       (page generated 2020-09-01 23:01 UTC)