go-sqlmock
go-sqlmock copied to clipboard
DATA-DOG
Options for non-strict mock - allow unexpected calls
While strict mock is very valuable, it's also very restrictive in how we can use this library. strict mocks force all expectation to be met, and also that anything that happens on the mock was expected.
This makes tests break for unrelated changes, and encourages tests that verify a lot of behaviors in a single test. for me, testing that a transaction gets commited in a specific case, is a different test than testing what query was sent.
It would be nice if we could add an option to sqlmock.New() that relaxes the expectations.
sqlmock.New(sqlmock.AllowUnexpectedCalls()) // or something similar
I would like to only fail the test if the expectation that I have defined are not met, but ignore calls that were not expected.
What is the point of a test if it is not strict? How can devs push commits without updates for tests? And why then you write tests in the first place?
You might want to test the behavior after the call to the DB, not the fact that the call was made. Unit tests are supposed to test one thing at a time.
Maybe I setup the DB with fake data, and run my tests, checking that I publish a message to Kafka. But I don't want necessarily to explicitly verify that each and every calls to the dB was made. And I don't necessarily want that the test breaks each time some code that touches the DB changes either.
"How can devs push commits without updates for tests?" I don't think this is a welcome way to answer a suggestion/contribution. I'm not asking how a dev can write so-called unit tests when he is testing more than one behavior at a time.
well, my intention for this library is to be used for unit tests. if you are testing a unit which is too large and may have unexpected behaviors in terms of interactions with db, then I do not think this library is suitable. If we add such features like, allowing repeatable calls or non explicit matching, then the library would turn into something different. The change you are proposing, is not correlating with the way I understand unit tests and I cannot accept it. I imagine there might be cases when it may be useful to do it in different way, but for that, there is a forking option if you do not fit in 90% of use cases. Adding that other 10% of corner cases, would make the library lose the purpose and become bloated and even confusing. I've built a few open source libraries, which are widely used and most often, if trying to satisfy all the possible use cases, it becomes more confusing and in the end unusable.