3 ms·
I always personally use "lasagna code" to discuss code that was over-abstracted with layers to the point of unreadability. Spaghetti code is a bad thing; I don'
by jdmichal 10y ago
I always personally use "lasagna code" to discuss code that was over-abstracted with layers to the point of unreadability. Spaghetti code is a bad thing; I don't see why lasagna code would be a good thing. Is it common to have a positive connotation here that I'm just unaware of?
> The point is that mocks make us test the wrong things. A test should assert behaviours in the form of outputs for a given input, not by verifying if a certain method is called or not. Mocks focus on implementation, while the results are what we actually care about.
Mocks test the external behavior of a component, and they do that perfectly well. The problem with mocks is that they don't test your assumptions about how those interactions should work, compared to how they actually work. I can use mocks to test that certain SQL statements are being generated, but that doesn't help if there's a fundamental error in my assumptions about how SQL statements work.
- junke 10y agoHaving separate layers of abstraction is a good approach in general: see "Abstraction Barriers" from SICP (https://mitpress.mit.edu/sicp/full-text/sicp/book/node29.html https://mitpress.mit.edu/sicp/full-text/sicp/book/node29.htm...). Lasagna code is abstraction done wrong, with possibly too many layers or leaky abstractions (like in a real Lasagna).
- Sharlin 10y agoRight. Unit tests are about ensuring individual modules work correctly. Integration tests are about ensuring modules work together correctly.