How to learn to write unit tests that make sense and not get bored?

Question

Java

I want to confess: in my entire life I have written less than 10 unit tests. This is despite the fact that I love and often write library projects. Every time before starting a project, I tell myself: this time I will write unit tests. Naturally, I break my promise.
In justification, I can say that I simply do not understand how to approach this task. Let's say I wrote a container in Java. But in order to at least half cover the qualitatively different states of the container with tests, you need to write several times more code than the container itself takes! What if it contains weak links? What if it's thread-safe? The tests themselves in these cases become difficult to write. Especially if they are correct.
I see that the more complex the interface, the more difficult it is to test it many times over.
Question: is there something that significantly simplifies the problems described above. Well, for example, test templates for the same containers. Or systems that make it easier to test thread-safe code. Or is it possible to stop worrying and write only high-level tests? Or am I misunderstanding something globally?
By the way, the question is not Java-specific.

Answer 1

A familiar problem. It's good to write tests for simple functionality. But what to do when you need to test not just individual functions, but also their combinations? What to do when the number of combinations of input data is huge, or even infinite, and each combination can lead to an error?
I found a partial solution for myself: I write high-level tests, and I replace low-level ones with a lot of asserts. Assert is easier to write because you do not need to reproduce the context either programmatically or mentally - assert is always executed in the right context. And when running a high-level test, many more checks are actually performed than what is written in the test itself. Assert-you are also very helpful in debugging - with their help, errors are localized faster.
By the way, for library projects it is absolutely necessary to write projects that use these libraries. Otherwise, the library is guaranteed to be unnecessary. So, such an application itself and tests for it are at the same time tests of the library.

Answer 2

I suppose that's why they hire individuals who write only tests.

Answer 3

Well, first of all, writing several times more code is not a problem. For there is a rule: "writing code is not the bottleneck of development." The bottleneck is, for example, the constant reengineering of the design. There should be more tests than basic code, but test code should be simple and easy to write. Something was given as an input, something was received as an output.
As for complex tests, the problem is in the design of the code. To properly design, you need not small skills. I run into these issues all the time too. But over time, I understand that many things that previously seemed untestable are now clear how to rewrite them so that they can be easily tested. The main motivation. Who wants - looking for opportunities. Who does not want - looking for reasons.
And lastly, there are always things that are practically impossible to test, such as multithreading. This is fine. It just needs to be localized.

Answer 4

Since the question is in general, in general, reducing the use of states reduces the complexity of testing. For example, when using the functional style.

Answer 5

       Try reading about TDD - Test-driven development. This is a test-driven development technique that allows you to make the process of writing unit tests part of writing code, or rather, you will write code that would satisfy the written test. This technique will make the process of writing unit tests much more interesting and efficient, and the time spent on coding in general will decrease, because the time usually spent on debugging and finding errors will decrease.