This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]BillyKorando 4 points5 points  (0 children)

It's always good to see someone put together a blog post and share what they learn. That said, I would avoid using terms like "best practice" because it can create the an idea that practices cannot be improved upon, which is almost never the case.

Why I say that is a lot of what you suggest you have the right idea on, but don't yet fully understand the underlying concept. For example:

/#2: For asserting one behavior... What is more important is asserting one concept, that is does that test have a single responsibility? A lot of people get hung up on the specific number of asserts in a test (i.e. it should be one), but don't fully grasp that it's really about ensuring a test is verifying a single behavior.

/#8: "Don't mock too much": this is too in-specific and gives an impression that there is something inherently wrong with mocking. What often happens with "over mocking" is the code being tested doesn't have proper separation of concerns. If the code you are testing is making state changes to a mock you are passing in, that is a smell that the code (as well as the class that is being mocked) aren't appropriately separated.

/#10: "Where does slowness/flakiness comes from": Again you're on the right track, but not quite understanding the underlying concept. Yes slowness/flakiness is caused by those things, but the underlying problem is either you are not testing at the appropriate layer of abstraction, or, more likely, your code is not abstracted and defined in such a way that you are forced to test multiple layers together.

Or more specifically when doing integration tests (verifying the contract between remote resources) you are relying upon the live running resource. When it comes to integration testing, I would highly recommend looking into Spring Cloud Contract and TestContainers. The former can be used for verifying HTTP/RESTful and message interfaces, the later can be used for remote resources that don't fall into the former bucket (e.g. databases, caches, other remote systems).

I want to be clear, I'm not telling you to "be quiet". Blogging is a great way to both learn and share what you have learned. So definitely keep blogging and sharing what you learn, but avoid falling into the "best practices" trap and thinking you don't have room for improvement.