2 ms·
> Most people write terrible tests, which are over mocked. You should test input(say simulate http post call) then check the thing is in the fake database You'
by u801e 7y ago
> Most people write terrible tests, which are over mocked. You should test input(say simulate http post call) then check the thing is in the fake database
You're still using mocks in that case. You can avoid using mocks entirely by decoupling your tests from external dependencies. That is, instead of making a HTTP post request to the application, test a method that takes the content of the HTTP request as a parameter and assert on the return value. For the database, you can test a method that takes parameters and returns the appropriate query.
Then integration tests can be used to test the interactions between different parts of the system.
- UK-Al05 7y ago" That is, instead of making a HTTP post request to the application, test a method that takes the content of the HTTP request as a parameter and assert on the return value" The http post is the input into OUR system under test, not an external dependency. Nothing is mocked. I find going through the entire http pipeline catches misconfiguration issues. "For the database, you can test a method that takes parameters and returns the appropriate query." - That's what the fake database does. Implements the interface to the database. In this case implements a fake query method. Nothing is mocked. Stubed but not mocked.