[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)