Great vid. On mocking, I think you should be mocking as well as testing against the real thing. Mocks give you a chance to test any transient errors, and add regression tests.
I think mocks should be used for external services. These services have their own tests and are considered "OK" in most cases and not a concern of a current implementation. DB I consider as a local resource and should not be mocked IMHO. There are many cases where the query run on DB may produce wrong results and mocks will hide your poor assumptions on groupings, joins etc... The external services working testing is done during e2e which validates that your new changes are compatible in whole application.
That’s the point of an integration test tho . Integration test tests the thing as a whole . I don’t see the repository pattern as a bad way to implement it .
Great video! I'd like to add another perspective on the overuse-of-DRY point. No question, coupling call sites in the name of avoiding similar looking code soon leads into an entangled mess. The root cause, I think, is a misunderstanding of what DRY originally meant. Citing from The Pragmatic Programmer: 'Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.' As such, it was not meant to be about minimising similarities. Rather, if and only if there is some specific decision, domain concept, technical pattern (knowledge) which can be abstracted, then to define that abstraction only once and use the abstraction. Understood as such, the contraindication is quite similar to the point made towards avoiding interfaces: if code (in the broadest of meanings) seems similar, but there is no well-definable abstraction behind that similarity, by all means, DO repeat yourself in order to avoid harmful coupling of things fundamentally unrelated. Maybe not surprisingly, in the section on DRY, Hunt and Thomas explain over eight pages how impatient/premature avoidance of repetition is harmful.
Great vid. On mocking, I think you should be mocking as well as testing against the real thing. Mocks give you a chance to test any transient errors, and add regression tests.
You should ensure your mocks produce failure conditions, otherwise yes they're basically useless.
I agree. Mocks are an abstraction. Have you ever had to mock for a system you don’t have access to? How would you test locally then
I think mocks should be used for external services. These services have their own tests and are considered "OK" in most cases and not a concern of a current implementation.
DB I consider as a local resource and should not be mocked IMHO. There are many cases where the query run on DB may produce wrong results and mocks will hide your poor assumptions on groupings, joins etc...
The external services working testing is done during e2e which validates that your new changes are compatible in whole application.
@@klamberext it depends. Setting up dbs for tests can make your test runs longer by a significant margin but it does give you more confidence
Thanks for taking the time to put this together - great insights!
That’s the point of an integration test tho .
Integration test tests the thing as a whole .
I don’t see the repository pattern as a bad way to implement it .
Great video!
I'd like to add another perspective on the overuse-of-DRY point.
No question, coupling call sites in the name of avoiding similar looking code soon leads into an entangled mess.
The root cause, I think, is a misunderstanding of what DRY originally meant.
Citing from The Pragmatic Programmer:
'Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.'
As such, it was not meant to be about minimising similarities.
Rather, if and only if there is some specific decision, domain concept, technical pattern (knowledge) which can be abstracted, then to define that abstraction only once and use the abstraction.
Understood as such, the contraindication is quite similar to the point made towards avoiding interfaces: if code (in the broadest of meanings) seems similar, but there is no well-definable abstraction behind that similarity, by all means, DO repeat yourself in order to avoid harmful coupling of things fundamentally unrelated.
Maybe not surprisingly, in the section on DRY, Hunt and Thomas explain over eight pages how impatient/premature avoidance of repetition is harmful.
Agree with many of these including Mocking and DRY.
really informative video, not sure why people are disliking.
I wish I knew enough to understand most of this
Use mocks for unit testing. Use the real thing for integration testing.
Based
One more: not using Context.
nice #amflearningbydoing #amflearning