Tag Info

Hot answers tagged

63

A lot of people think that unit testing is method-based; it's not. It should be based around the smallest unit that makes sense. For most things this means the class is what you should be testing as a whole entity. Not individual methods on it. Now obviously you will be calling methods on the class, but you should be thinking of the tests as applying to ...


51

The fact that your data-gathering methods are complex enough to merit tests and separate enough from your primary goal to be methods of their own rather than part of some loop points to the solution: make these methods not private, but members of some other class that provides gathering/filtering/tabulating functionality. Then you write tests for the dumb ...


35

Units I think I can pinpoint exactly where the problem started: I figured, I'll need a method that finds all the non-numerical fields in a line. This should be immediately followed with asking yourself "Will that be a separate testable unit to gatherNonNumericColumns or part of the same one?" If the answer is "yes, separate", then your course of ...


29

Personally, I feel you went to far into the implementation mindset when you wrote the tests. You assumed you would need certain methods. But do you really need them to do what the class is supposed to do? Would the class fail if someone came along and refactored them internally? If you were using the class (and that should be the mindset of the tester in my ...


9

You don't do TDD based on what you expect the class will do internally. Your test cases should be based on what the class/functionality/program has to do to the external world. In your example, will the user ever be calling your reader class with to find all the non-numerical fields in a line? If the answer is "no" then it's a bad test to write in the ...


8

You are encountering a common misconception with testing in general. Most people who are new to testing start out thinking this way: write a test for function F implement F write a test for function G implement G using a call to F write a test for a function H implement H using a call to G and so on. The problem here is that you in fact have no unit ...


7

The tests that you write during Test Driven Development are supposed to make sure that a class correctly implements its public API, while simultaneously making sure that that public API is easy to test and use. You can by all means use private methods to implement that API, but there is no need to create tests through TDD – the functionality will be tested ...


5

In their book Growing Object-Oriented Software, Guided by Tests, Steve Freeman and Nat Pryce tackle this very issue. I do recommend that as a worthy read, since it's full of interesting examples and I'll probably just misquote, anyway. Rephrasing, they argue that instead of mocking the external API you have no control over, you should create a layer of ...


4

I think the right answer is the conclusion you came to about starting with the public methods. You would start by writing a test that calls that method. It would fail so you create a method with that name that does nothing. Then you maybe right a test that checks for a return value. (I'm not entirely clear as to what your function does. Does it return a ...


3

As you noticed, the TDD mantra of only writing code in response to a failing (unit) test starts to break down when you approach a system boundary where you need to integrate with hardware or third-party code. You started out right by defining an abstraction layer over the SDK (in the form of the IHardware interface) and writing your code against that ...


3

Abstracting away the 3rd party dependency like you did does not only benefit testing, as it also makes your code more robust against changes in the dependency (by effectively wrapping it/creating your own adapter). Testing that the real 3rd party product does what you think it does when receiving commands from your code might not be possible in the context ...


3

it feels like I've painted myself into a corner here. But where exactly did I fail? There's an old adage. When you fail to plan, you plan to fail. People seem to think that when you TDD, you just sit down, write tests, and the design will just magically happen. This isn't true. You need to have a high level plan going in. I've found that I get ...


2

There are times when a private method could be made a public method of another class. For example, you might have private methods that are not thread-safe and leave the class in an temporary state. These methods can be moved to a separate class which is held privately by your first class. So if your class is a Queue, you could have an InternalQueue class ...


2

Remember that tests can be refactored too! If you make a method private, you're reducing the public API, and hence it's perfectly acceptable to throw away some corresponding tests for that "lost functionality" (AKA reduced complexity). Others have said your private method will either be called as part of your other API tests, or it will be unreachable and ...


2

I would start with eliminating the duplicated code first by building a generic creation service, something along the lines of class GenericCreatorService<T> { UnitOfWorkFactory _unitOfWorkFactory; // ... public T Create(Func<T,UnitOfWork> func) { using (var unitOfWork = ...


1

Inject the three Creator-classes and test the calls to them by unittesting the QuickOrderService. This keeps the tests on the relevant classes. Also, you might not need to haul the unitOfWork around. The implementation of Create could be changed to simply create a new transaction if none exists and otherwise return the existing transaction. This could keep ...



Only top voted, non community-wiki answers of a minimum length are eligible