4 ms·

> Maybe only for documentation purposes in legacy systems. > people maintaining your code after you've left the company That's what a legacy system is. I agre

> Maybe only for documentation purposes in legacy systems. > people maintaining your code after you've left the company That's what a legacy system is. I agree. That's a good use of tests. But don't start WITH them. You'll build rigid systems. > Well... That's where the money's at, right? Agree with this also. But this is (or should be) hacker news, so we look for better ways to make software, regardless if it makes money or not. Or maybe we should rename it Financial Times?

UK-Al05 7y ago
"But don't start WITH them. You'll build rigid systems" - Only if you design them badly. 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 or even better a call to retrieve the item. You can completely change the way its implemented in between.
- 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.
- nicoburns 7y ago
  > You should test input(say simulate http post call) then check the thing is in the fake database or even better a call to retrieve the item. Agree. The key to good tests seems to make them neither unit tests or e2e tests, but something in between. API tests if you have an API, or "medium sized module" tests in other systems. Unit tests and e2e tests have value too, but they're a lot more work to maintain for less value IMO.
mateuszf 7y ago
> But don't start WITH them. You'll build rigid systems. It depends. If you'll test implementation - sure. But if you test use cases - not necessarily,

UK-Al05 7y ago

"But don't start WITH them. You'll build rigid systems" - Only if you design them badly. 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 or even better a call to retrieve the item. You can completely change the way its implemented in between.

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.
nicoburns 7y ago
> You should test input(say simulate http post call) then check the thing is in the fake database or even better a call to retrieve the item. Agree. The key to good tests seems to make them neither unit tests or e2e tests, but something in between. API tests if you have an API, or "medium sized module" tests in other systems. Unit tests and e2e tests have value too, but they're a lot more work to maintain for less value IMO.

mateuszf 7y ago

> But don't start WITH them. You'll build rigid systems. It depends. If you'll test implementation - sure. But if you test use cases - not necessarily,