I've been struggling on that topic for a few hours now and what you nicely shows here in your post is not acceptable for me, except for an "hello world!" app.
I can't imagine writing the mocks for each dependency by myself, and above all, I can't imagine modifying my code to replace my dependencies by my interface.
It must be possible with reflection, no?
If you know a way to do that properly like with doubles in PHPUnit, or with mocks in Java/Mockito, then I'm interested!
your post is not acceptable for me, except for an "hello world!" app.
Well what can I say, I and many others take this approach for large applications and it's fine.
Writing mocks, especially if you have an IDE that lets you auto implement interfaces at a keystroke is very trivial.
You can also do embedding if you wish to only mock a part of an interface
typeMyStubstruct{MyInterface}//todo: impl just the method you need
I'm not sure using reflection is any more "proper". In my experience mockito and the like give you a superficial "easiness" but then run into the usual problems with reflection which are a lack of clarity, type-safety and speed.
Debugging null pointer exceptions with my oh-so-easy mocks in mockito have wasted too much of my life already.
There are auto mocking libraries out there for Go of course, but I steer clear of them. I think GoMock is used by some.
Think about why you need to set up so many mocks. Are you over-testing things? Is the design of your system right?
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.
I'm very confused with mocking in Go.
I've been struggling on that topic for a few hours now and what you nicely shows here in your post is not acceptable for me, except for an "hello world!" app.
I can't imagine writing the mocks for each dependency by myself, and above all, I can't imagine modifying my code to replace my dependencies by my interface.
It must be possible with reflection, no?
If you know a way to do that properly like with doubles in PHPUnit, or with mocks in Java/Mockito, then I'm interested!
Anyway, thanks for this great article!
Well what can I say, I and many others take this approach for large applications and it's fine.
Writing mocks, especially if you have an IDE that lets you auto implement interfaces at a keystroke is very trivial.
You can also do embedding if you wish to only mock a part of an interface
I'm not sure using reflection is any more "proper". In my experience mockito and the like give you a superficial "easiness" but then run into the usual problems with reflection which are a lack of clarity, type-safety and speed.
Debugging null pointer exceptions with my oh-so-easy mocks in mockito have wasted too much of my life already.
There are auto mocking libraries out there for Go of course, but I steer clear of them. I think GoMock is used by some.
Think about why you need to set up so many mocks. Are you over-testing things? Is the design of your system right?
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.