40,283 reputation
1393183
bio website
location London, United Kingdom
age
visits member for 3 years, 6 months
seen 23 hours ago

Apr
23
comment How would you explain this line of code to a complete beginner?
@Prog: Is there a reason you can't take it step-by-step? Write the scanner code in-line, then extract it to a method, then move it to a class?
Apr
23
comment Testing in procedural programming code
@user2250119: perl.org/get.html
Apr
23
answered Testing in procedural programming code
Apr
15
comment Testing abstract class' behavior
Yeah, that's one of those cost-benefit decisions you have to make sometimes. I would test both, doing whatever I could to remove duplication from the test code. I don't know C++ testing frameworks very well, but in NUnit, you can have base test classes from which you can derive others, so you can very easily say "all classes that derive from type A must satisfy these conditions". Then if, later, that becomes untrue -- eg. if the implementation is moved to the derived classes -- you can also move the test to the derived test classes and run before changing your code.
Apr
14
comment Testing abstract class' behavior
@MetaFight: Correct.
Apr
14
comment Testing abstract class' behavior
@MetaFight: No, I'm not suggesting that. I'm suggesting that if I call DoStuff() on a derived class, the expected behaviour (which is what I should be testing) is a behaviour of that derived class, even if it is ENTIRELY implemented in the base class. I am distinguishing between behaviour and implementation details. That is, if I decide later that DoStuff() should be implemented in the derived class, or a helper class, instead then the behaviour of that class doesn't change (though other derived classes might) and neither should the tests.
Apr
14
comment Testing abstract class' behavior
Behaviour shouldn't belong to an abstract superclass though. That's the point of its being abstract, surely. The behaviour is a property of the subclass; that it has a superclass is an implementation detail.
Apr
14
comment Testing abstract class' behavior
And all that is assuming you've actually considered and discounted preferring composition over inheritance. en.wikipedia.org/wiki/Composition_over_inheritance
Apr
14
comment Testing abstract class' behavior
How does instantiating an object of the subclass make the tests confusing? In most cases, your tests shouldn't even know there is a superclass; the only thing that matters is the subclass. In the few cases where you really want to test an abstract superclass, the first option is preferable.
Apr
6
comment If TDD is about design why do I need it?
@Aaronaught: I don't believe you genuinely think that's what I'm saying and I'm not entirely sure why we're debating an answer from 2.5 years ago. I do vaguely remember this being part of a series of questions from idsa, and I think my answer was partly in context of others. Your answer is a good one and probably deserved to be the accepted answer, in hindsight, but I think we both know that's not always how it goes on Stack Exchange.
Apr
6
comment If TDD is about design why do I need it?
@Aaronaught: Hmm. That's not really what I said, was it? I said it helps me get to the best final design in the fewest attempts. "Best" is a bit subjective, I admit, but my point is that Ron Jeffries would probably have come to the same design, given long enough, as he did using TDD. And he probably got there in fewer attempts using TDD. Whether or not his design is good is entirely another question. And when we have a technique that makes average code-designers into good designers, that will be another thing entirely again.
Apr
6
awarded  Popular Question
Apr
2
comment Zero behavior objects in OOP - my design dilemma
Also related: stackoverflow.com/questions/7177904/worker-vs-data-class
Apr
2
comment Zero behavior objects in OOP - my design dilemma
Some of your premises here are completely wrong, which is going to make answering the underlying question very difficult. Keep your questions as concise and opinion-free as you can and you will get better answers.
Apr
2
comment Zero behavior objects in OOP - my design dilemma
Don't disagree with anything you've said, but this doesn't answer the question at all. That said, I blame the question more than the answer.
Mar
28
comment Iteratively building a Test Framework
Sorry, I've tried to answer it and realised that I still don't really understand the problem. Can you try to refine the question? Get rid of all the fluff; it's not important that we know about your workplace or how much Agile experience you have. What's important is that we understand exactly what you are trying to solve. Using correct terminology helps us a lot.
Mar
28
comment Iteratively building a Test Framework
Framework is a bit of a vague term, I guess. Google Test is a framework. Your infrastructure that runs Google Test is a framework. Arguably, even any standards you set up are a framework. In essence, everything that isn't unique to the problem at hand -- in this case, the test code -- is a framework within which the code that IS unique to the problem at hand will run. With that in mind, and now understanding what you meant, I'll try to answer your question shortly.
Mar
27
comment Iteratively building a Test Framework
I guess I might be misunderstanding what you mean by framework. Is it not a set of solid, somewhat-standardised tools?
Mar
27
comment Iteratively building a Test Framework
Why is setting up a framework "putting the cart before the horse"? I'm a bit lost by that.
Mar
21
comment Why write tests for code that I will refactor?
Your first paragraph appears to be advocating ignoring step 1 and writing tests as he goes; your second paragraph appears to contradict that.