You may be pointing out something interesting: maybe I am over-testing things, sometimes.
I love this concept in Go, where you craft many things by yourself.
This is achieved thanks to the great standard library.
That's why no framework emerged, unlike Laravel in PHP or Spring in Java.
In PHP, I was used to unit test every single part of my code, by mocking the sub-dependencies of my functions, and by spying calls.
By the time, it always become a kind of hell to maintain.
Maybe in Go, I could be a little less exhaustive in unit testing, and rely more on the strong typing. I mean, testing the inputs & outputs of my web APIs should be enough most of the time. But in some cases, I still need to check that data are written in db or that a log in sent to stdout because we have dashboards that consume it and this is critical for the business.
Thank you for your answer, it helped me to better understand what I really need.
Static typing certainly removes a lot of the tests you would need in a dynamic language but you still benefit from tests
I allude to this in the book in various chapters about how you should favour testing behaviour over implementation detail. It's a myth that unit testing means "tests on classes/functions/whatever" You write unit tests on behaviour, that could be a class which has a number of internal collaborators. You dont have to test them. In fact by testing them you may harm your efforts if you wish to change the implementation (refactoring)
i plan to do a talk/blog on this subject in more detail... sometime when i get the time.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
You may be pointing out something interesting: maybe I am over-testing things, sometimes.
I love this concept in Go, where you craft many things by yourself.
This is achieved thanks to the great standard library.
That's why no framework emerged, unlike Laravel in PHP or Spring in Java.
In PHP, I was used to unit test every single part of my code, by mocking the sub-dependencies of my functions, and by spying calls.
By the time, it always become a kind of hell to maintain.
Maybe in Go, I could be a little less exhaustive in unit testing, and rely more on the strong typing. I mean, testing the inputs & outputs of my web APIs should be enough most of the time. But in some cases, I still need to check that data are written in db or that a log in sent to stdout because we have dashboards that consume it and this is critical for the business.
Thank you for your answer, it helped me to better understand what I really need.
Static typing certainly removes a lot of the tests you would need in a dynamic language but you still benefit from tests
I allude to this in the book in various chapters about how you should favour testing behaviour over implementation detail. It's a myth that unit testing means "tests on classes/functions/whatever" You write unit tests on behaviour, that could be a class which has a number of internal collaborators. You dont have to test them. In fact by testing them you may harm your efforts if you wish to change the implementation (refactoring)
i plan to do a talk/blog on this subject in more detail... sometime when i get the time.