Tag Info

New answers tagged

2

After watching this amazing talk "Ian Cooper: TDD, where did it all go wrong", I'm going to disagree with @pdr. I think you should only keep the original tests. Your ability to refactor your system under test without breaking, writing or changing any tests is the whole purpose of writing tests in the first place. If I were to test the extracted class, ...


1

From a testing perspective there are some requirements that are an absolute must: Testing (unit or otherwise) must never have a way to touch production data The results from one test must never affect the results of another test You must always start from a known position That's a big challenge when connecting to any source that maintains state outside ...


1

TL;DR - The way I see it, it depends on how much effort you end up spending on tests, and whether it would have been better to spend more of it on your actual system instead. Long version: Some good answers here, but my take on it is different: testing is an economic activity that needs to pay back for itself, and if the time you spend isn't returned in ...


3

I agree completely with the response of guillaume31, never mock types that you don't own!. Normally a pain in the test (mocking a complex interface) reflect a problem in your design. Perhaps you need some abstraction between your model and your data access code, form example using an hexagonal architecture and a repository pattern its the most usual way to ...


17

My first recommendation would be to not mock types you don't own. You mentioned HTable being a real pain to mock - maybe you should wrap it instead in an Adapter that exposes the 20% of HTable's features you need, and mock the wrapper where needed. That being said, let's assume we're talking about types you all own. If your mock-based tests are focused on ...


10

philosophically, tests that use mocks should take priority over tests that use a live endpoint I think at the very least, that's a point of current ongoing controversy amongst TDD proponents. My personal view goes beyond that to say that a mock-based test is mostly a way of representing a form of interface contract; ideally it breaks (i.e fails) if ...


5

How much longer does an endpoint-based test take to run than a mock-based test? If it's significantly longer, then yes, it's worth the investment of your test-writing time to make the unit tests quicker - because you'll have to run them many, many times. If it's not significantly longer, even though the endpoint-based tests are not "pure" unit tests, as ...


5

In general, unit testing should test your code, not the code of some library. Presumably the library already contains its own unit tests. Certainly, one or two unit tests would help you get the feel of the library and how it works. But detailed testing of this kind generally falls under the purview of integration testing.



Top 50 recent answers are included