Depends on what you want to accomplish. With test mocks you are trading off certainty for cost and cost increases exponentially as you add more and more certainty.
For example, you could write a test suite that takes 20 hours and you are 99.999999999% certain it will work. Or you could write a test suite that runs in 2 seconds but you are now only 99.9999% certain it will work.
I prefer cheap tests, so I usually follow a flow chart like this:
=> Do I mock it? <=
Is it slow?
true false
=>yes<= Do we control when changes happen?
true false
=>no<= =>yes<=
You can also do certain things to ensure mocks aren't out of sync. In Ruby you can compare method arity prior to running the tests. In static languages you could probably have the compiler do something similar.
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.
Depends on what you want to accomplish. With test mocks you are trading off certainty for cost and cost increases exponentially as you add more and more certainty.
For example, you could write a test suite that takes 20 hours and you are 99.999999999% certain it will work. Or you could write a test suite that runs in 2 seconds but you are now only 99.9999% certain it will work.
I prefer cheap tests, so I usually follow a flow chart like this:
You can also do certain things to ensure mocks aren't out of sync. In Ruby you can compare method arity prior to running the tests. In static languages you could probably have the compiler do something similar.