Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Most Unit Testing Is Waste (2014) [pdf]

rbcs-us.com

Post reply on HN
Print view View original

161–164 of 164 posts

Re: Most Unit Testing Is Waste (2014) [pdf]

#161

Post by hhjinks »

Mandatum wrote: post #149
hhjinks wrote: post #100

Earlier quoted context omitted.

I personally find testing incoming APIs a waste. Sometimes I write tests to verify that I treat the incoming data correctly if I transform it in fancy ways, but other than that, you should trust the API contract. It's almost like writing tests for the frameworks you're using. Granted, that's from a unit test perspective. Integration tests of APIs are invaluable. I wish we had them already where I currently work.

> but other than that, you should trust the API contract As someone who's been working in corporate integration for the past 6 years.. Never trust a contract. Be in WSDL, OpenAPI spec, Word documents or otherwise. I've worked with large tech vendors, I've worked with finance, I've worked with large consultancies. The only people that seem to get it right, is the people you don't want to work with because it's soul-cr…

The point is you can't write unit tests for broken API contracts, so either you trust that the contract is upheld, or you've got bigger problems on your hands.

Re: Most Unit Testing Is Waste (2014) [pdf]

#162

Post by Mandatum »

hhjinks wrote: post #161
Mandatum wrote: post #149

Earlier quoted context omitted.

> but other than that, you should trust the API contract As someone who's been working in corporate integration for the past 6 years.. Never trust a contract. Be in WSDL, OpenAPI spec, Word documents or otherwise. I've worked with large tech vendors, I've worked with finance, I've worked with large consultancies. The only people that seem to get it right, is the people you don't want to work with because it's soul-cr…

The point is you can't write unit tests for broken API contracts, so either you trust that the contract is upheld, or you've got bigger problems on your hands.

Do you mean integration tests? I don't think API contracts should be a part of a unit test. A unit test should be self-contained, unless of course there is a tight coupling to an API.. Which I would steer clear from.

That's why I value integration tests over most thing. I can see immediately that something is broken at a high level, what business impacts it has and explain what systems are affected.

Re: Most Unit Testing Is Waste (2014) [pdf]

#163

Post by winrid »

msclrhd wrote: post #152
winrid wrote: post #130

Earlier quoted context omitted.

Because if you're not using mocks the tests get unweildy. Suddenly changing components three layers down the dependency tree breaks "unit" tests at the top. Those are the tests you just end up @ignore'ing.

Mock things like database access, or better yet pass the database connection via an interface and create a test version of the database access so you can create a database-like thing for your tests (e.g. an in-memory database). If you are depending on another component of the application (a lexer, a JSON class, a maths function, etc.) don't mock that because if that class breaks you want tests to fail instead of sile…

As someone that has written thousands of tests - what I disagree with you on is when writing unit tests those application components should have their own tests. Then you can cleanly mock them. Even if they are utilities etc.

Same goes for application code in the same service or whatever. Mock those calls and only test your unit of code.

If you don't do this things can be fine. But at some point the code base will become unwieldy and changing code in one place will break tests all over the place.

Integration tests are fine and they have their place but are not a substitute for proper unit tests.

Post reply on HN