What I learned using unit tests/TDD

http://pauloortins.com/lessons-unit-tests/

by pauloortins • 13 years ago

44 57 13 years ago

showsover• 13 years ago

I must admit that I don't fully do TDD, but sometimes it helps me getting my tests out first, so that I can "figure out" what to do in my real code whilst running the tests.

I see the return values of certain functions and computations, and while debugging my failing test, I can see a path to the solution I need.

Once the test succeeds, it's time to clean up the ugly code and refactor it into clean subsections, be it functions or classes.

So yeah, TDD is a great tool. One of many in my toolbox.

pauloortins8• 13 years ago

I love clean and well-written code but to achieve clean code we should be able to refactoring without break our code. This is the point for TDD.

_pmf_• 13 years ago

I love clean and well-written code but to achieve clean code we should be able to refactoring without break our code. This is the point for TDD.

That's also true for vanilla regression tests. There's nothing special that TDD adds in this regard.

kellros• 13 years ago

Thanks for sharing, I agree with the points you made. The only thing I would add is that not everything is testable in the sense of given: input, expect: output.

A common scenario I encounter is that sometimes when you are refactoring a method and refactoring it into multiple methods (for better readability or segregation); that you are required to make the new (sub) methods publicly available for testing purposes. This goes against the intention of improving readability because now you have to expose certain methods that you would rather haven't be called independently. In such way, TDD helps identify artifacts with too many responsibilities.

The best tip I can think of to give someone approaching/doing TTD is to make a check-list beforehand of what you are trying to achieve. This helps to focus your attention on usage patterns and identify 'end-points' (end points being testable artifacts). Just because you're doing TDD, doesn't mean you don't have to have a plan to start with.

pauloortins8• 13 years ago

When talking about this common scenario, there are two ways of think. Some people argue that you shouldn't expose private methods only to test them. You should do it through the public method to keep the encapsulation. Others argue that yes, you should expose these methods to make easier to write tests and to identify possible bugs.

It depends, we have to analyze each case and choose the advantages and disadvantages.

PaulHoule• 13 years ago

In Java you don't have to make the methods public, you can just make them default scope. The test cases can see them because they are in the same package but the rest of the system can't.

prawks3• 13 years ago

I'd imagine this is similar to "internal" in C#. If so, that still doesn't equate to being private, as other objects can see them within the package/assembly. To the outside world this is fine, of course, however it removes that additional organizational capability within the package.

lazerwalker• 13 years ago

I've often found that not being able to test something in a sense of "given: input, expect: output" is a smell that you're taking the wrong approach and that a better factoring for your code exists (this obviously isn't always the case, perhaps the most common exception being testing integration with third-party code).

wildwood• 13 years ago

There's nothing requiring you to specifically test every function in a class - though, as others have said, you can set the access level to default or protected to have package-level access for tests.

Strictly speaking, though, refactoring should never require new tests, unless you're specifically refactoring to increase testability. New tests should be related to specific bugs or feature requests.

z0r• 13 years ago

How many of the <fixnum> benefits of TDD and unit tests are achievable through the use of sufficiently advanced type systems? Disclaimer: I'm not using advanced type systems to replace unit tests myself, but the more I read about them the more I suspect that most of the tests I've ever worked with (a small sample to be sure) could be obviated by pushing the logic they test for into structured types.

prawks3• 13 years ago

This is one thing that has irked me a little bit as I've gotten more involved with TDD and unit testing in general: the logic in many of my unit tests is near duplicate logic that is implemented within my application.

My thought is that the general advantage of TDD is that you are thinking about your eventual implementation from the outside. You write tests in a different mindset based on expectations, rather than when you are implementing the production code where you are more concerned with the details of logic, etc. Unit tests also tend to be a bit more readable than the actual implementation logic, and so act as a nice form of documentation as a side-effect. In this way, test-first development provides a more gradual transition between a specification or design and the end implementation, which results in fewer missed requirements, allows for easy refactoring, etc.

This is of course only related to TDD however, not unit testing in general. Hence, it still irks me that many of my tests look so similar to the logic they are testing, and thus aren't really testing for correctness at all.

jacquesm• 13 years ago

Think of unit testing as auditing the contract between two pieces of code right at the interface by replacing one of the two pieces of code (usually the client or caller but you can replace the code that provides the response just as easily) by a program that exercises the other layer.

Like that you build your confidence layer by layer and with every set of tests you verify that you are still building on solid ground instead of quicksand.

That's why you test at the interface level, it allows you to swap out the implementation without having to re-work all the test code.

tieTYT2• 13 years ago

I went through a phase of this when I started writing automated tests. It occurred when I started using a mocking library for the first time. The library was so advanced I could basically test my implementation instead of my api. EG: "first you call foo.bar(), then you call foo.baz()" As a result, my test and my system under test looked very similar.

I'm not sure if you're in the same situation I was in, but let me tell you: My situation was an anti-pattern. All I was testing was that my code does what it does. I wasn't testing that my code was working.

Make sure you're not making the same mistake. If you are, a symptom would be that lots of tests fail when you're only refactoring.

nahname2• 13 years ago

Some issues are removed with a type system and wouldn't require writing tests to verfiy (the compiler would be doing this for you). I wouldn't take that fact as being in favor of using a type system, but more of a reminder that using a dynamic language without tests is reckless.

pauloortins8• 13 years ago

Type testing can be replaced by static types but you still have to test all the others stuffs in your code.

tmoertel• 13 years ago

Even with advanced type systems, the sweet spot will be a mix of types and tests. With types, you can prove many claims, including some you can't test for. With tests, you can gather evidence to support the claims you can't easily prove with types. So you need both.

Elaboration:

With advanced type systems you can prove that your code satisfies (or fails to satisfy) any property that you can encode as types. The more expressive the type system, the more properties you can encode, and the more kinds of claims you can prove.

But there will always be some properties that cannot be proved or that are too expensive to encode within a given type system. If you care about these properties, you'll have to find some other way of making sure they hold. So, even with advanced type systems, you'll end up writing tests.

The flip side is that there are many important properties that you cannot adequately test for (e.g., "my code is free of injection vulnerabilities"). If you're not using proofs to make sure that these properties hold, there's little reason to believe that they do hold, regardless of how much testing you do. So, even with lots of tests, you'll end up using types.

You need both.

tel6• 13 years ago

I find the decision tree tends to start with whether or not I even understand the problem well enough to generate constraints. After that there are serious questions (today) on whether it's worth formalization. After that, you're probably knee-deep in discovering the difficulty of any proof obligations you've given yourself. Then, finally, you can answer questions about how pervasive the encoding difficulty might be.

If those fail at any point it drives you to either use a more permissive type or to just test some useful cases. Not infrequently, test cases can be upgraded into more powerful types.

ExpiredLink• 13 years ago

UnitTests != TDD. Why is this confused so often? TDD is an optional variant to write tests. The benefits of TDD are questionable. The benefits of UnitTests are beyond question.

anon1385• 13 years ago

It's a deliberate marketing ploy by the TDD cultists. I see the same people doing it over and over again even after being corrected repeatedly.

skrebbel• 13 years ago

You seriously blame a vaguely defined, unorganized group of people of deliberate conspiracy?

A much simpler and less nasty explanation could be that to people who do TDD, the difference between 'doing TDD' and 'writing good unit tests' is completely uninteresting. It's all part of the same engineering practice.

This blog post clearly seems to target people with an interest in TDD, so I don't see what's wrong with that.

davidcuddeback5• 13 years ago

Actually, it's quite the opposite. TDD advocates and researchers have been trying to clarify the distinction for years. One of the motivating factors of BDD was to rebrand TDD with less of a focus on the word "test," because that word causes a lot of confusion among practitioners.

Also, please drop the word "cultists." You can disagree with a technique on legitimate grounds without resorting to ad hominems. I'm downvoting you because you're not adding any substance to the debate.

pauloortins8• 13 years ago

Nobody said that they are same thing. People often said that they use both.

papsosouid6• 13 years ago

Your article confuses the two constantly. You can't use TDD without using unit tests, TDD is a way of using unit tests. You can use unit tests without TDD. Most of what you talked about had nothing to do with TDD and was just about unit tests.

tieTYT2• 13 years ago

I don't get the context of your comment. Where is he confusing the two?

GhotiFish• 13 years ago

   it’s almost impossible and you will lose too much time
   but cover the majority of your code is perfectly 
   achievable. A good rule is test 
   *everything that can possibly break.*

but... but...

pbiggar• 13 years ago

To the OP: I wonder why you didn't recommend using Continuous Integration?

[disclaimer: I run a company that does hosted CI: https://circleci.com]

pauloortins8• 13 years ago

I recommend to use. But I never used, so I prefer to not talk about something that I can't explain how to use.

But yes, I think that Continuous Integration is a good practice.

What I learned using unit tests/TDD

Related Stories