Tag Info

New answers tagged

2

Contrary to popular belief, accessor methods do not provide any great advantage over direct field accesses, while in java they do tend to clutter the code with lots of gets and ()s. (Compare with C#, which has an awesome feature called properties, which look like fields but behave like accessors, saving you from all the mindless getSuchAndSuch()s and ...


0

I've experienced this and felt your pain. My solution was to: stop treating tests like building a monolith. Remember that when you have written a set of tests, lets say 5, to drive out some functionality, you don't have to keep all of these tests around, especially when this becomes part of something else. For example I often have: low level test 1 ...


-2

Does the sun revolve around the earth or the earth around the sun? According to Einstein the answer is yes, or both as both models differ only by the point of view, likewise encapsulation and test driven development are only in conflict because we think they are. We sit here like Galileo and the pope, hurling insults at one another: fool, don't you see that ...


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 ...


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 ...


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 ...


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 ...


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 ...


0

I occasionally have bumped private methods to protected to allow finer grained testing (tighter than the exposed public API). This should be the (hopefully very rare) exception rather than the rule, but it can be helpful in certain specific cases that you may run across. Also, that's something you would not want to consider at all when building a public ...


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 ...


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 ...


0

I wonder why your language only has two levels of privacy, fully public and completely private. Can you arrange your non-public methods be package-accessible or something like that? Then put your tests in the same package and enjoy testing the inner workings which are not a part of the public interface. Your build system will exclude tests when building a ...


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 ...


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 ...


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 ...


0

The source of the confusion here may be the fact that you are viewing the application object as being one and the same thing as the domain model of your application. They are not. The application contains the domain model, and instantiates the features that operate on it. So, my recommendation would be to take all these global variables out of the ...


1

I can not include Application header (since that would defeat the purpose of the separation). But since there are these types of globals everywhere in the old code this task is rather complicated. You just need to split the task into the correct steps, and then it is simple (though it may not be easy :) ) But sometimes there may be a lot of ...


2

I think it's perfectly OK for a "feature" to need an "application", but the use of globals is nauseating. Constructor dependency injection can solve this problem, and allow a gradual refactoring of code. (I'm not a C++ developer, so any corrections/clarifications are welcome) First, the Application class: class Application { public: void ...


4

What you are after is not very specific for OOP, and has absolutely nothing to do with inheritance. You are after proper modularization. Each of your features should be a component, that means either a single class, or a group of classes, with a well defined interface, and not directly dependent on the Application object. In the current situation each ...



Top 50 recent answers are included