One of the current pains we have in a project is the amount of mocks some classes need to actually be tested.
Is it desirable to not use mocks and use actual classes implementations? Then the test aren't in isolation tho.
This is where I think Unit Testings biggest strength is. If they are hard to write, it indicates problems in your code. In this case, overly complex classes and possibly a break in single responsibility.
Too many mocks can be a code smell. It could be your classes have too many dependencies or too many coupled pieces.
I also don't mock databases and will use a test one for each test run instead.
It could also be that you need more utility methods for testing.
Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink.
Hide child comments as well
Confirm
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.
One of the current pains we have in a project is the amount of mocks some classes need to actually be tested.
Is it desirable to not use mocks and use actual classes implementations? Then the test aren't in isolation tho.
This is where I think Unit Testings biggest strength is. If they are hard to write, it indicates problems in your code. In this case, overly complex classes and possibly a break in single responsibility.
Too many mocks can be a code smell. It could be your classes have too many dependencies or too many coupled pieces.
I also don't mock databases and will use a test one for each test run instead.
It could also be that you need more utility methods for testing.