Test Driven Development

IamtheWalrus

Hi all,

The project I am working on does not utilise TDD. I want to learn how to do TDD by myself.

Do any of you know how I could learn this skill? Most the of the work I do on my current project is about amending existing methods (we are in bug fixing phase). is there a way I could incorporate TDD myself on my work project or should I do some TDD at home?

Basically I want to add TDD to my CV and claim I've sued it commercially.

Is this possible?

Walrus

discodowney

TDD is just making automated tests that test any code you make. If you are making an API its pretty easy to implement. What is the project? What language are you using?

IamtheWalrus

discodowney wrote: »

TDD is just making automated tests that test any code you make. If you are making an API its pretty easy to implement. What is the project? What language are you using?

Java. I think it's more than just writing a test then writing code to make it pass. I've researched it and have done some tutorials via YouTube and I can see the value but the issue is putting it into practice on a real-life project where you are rarely writing from scratch and are working under pressure.

The project is on a website via Spring and Hibernate and web services.

discodowney

Ive only used Nunit but Junit is the Java version of that that is used for TDD (ive not used Spring/Hibernate but i think Junit is still used). You write the test as its meant to pass and then run the code against that. So any changes you make along the way the test will need to be updated to reflect them.

I do TDD every day (in C++/C#). The idea is that you have a suite of tests that have been developed from the start. Starting mid way through will be a bit of a pain alright. And take time. But the idea is that changes you make to the code base dont have unforseen consequences that affect other functions. So if you have 50 tests. You make a change to the code that seems to work fine. But it causes one of the 50 to fail. you know theres some problem with the code you just ran. The tests should be run every day/every check in (depending on how you are working). How large is the code base you are working with?

Gurgle

The premise is fairly straightforward, you should have a complete spec for each and every method/class/function before you begin to write it. You write a test first, then write your method/class/function, then test it.

In most cases, it achieves nothing. The focus is on testing, but whats missing from practically every project definition is a proper detailed spec. If the functionality and API is fully specified, writing the code to implement it is pretty much trivial. Writing tests for your own code is pointless in the real world, any pitfalls you miss in the implementation you'll miss in the testing.

But as its a commercial buzz phrase at the moment, it's worth getting on your CV. No harm doing it retroactively; prepare a detailed spec for some existing code, then write tests to confirm that it works as you intended.

IamtheWalrus

discodowney wrote: »

The idea is that you have a suite of tests that have been developed from the start.

So for anyone joining a project, someone will have already written this test suite so the suite is basically used to validate new code? Is this what's happens in the real-world?

I need to know how TDD works on real projects. Even if I do tutorials (I understand the idea and it's value) I still won't know how a large-scale project implements it and will be found out quickly in an interview.

IamtheWalrus

My current project is an Agile project. Using TDD, do I pick up a story, design what changes are needed then start writing tests, followed by code to pass the test? Is this really how it works or is that the 'ideal' but in practice it's much different?

discodowney

And new functions/code will cause more tests to be added to the suite. But any time a check in occurs the whole suite is run to ensure and new code/bug fixes/whatever havent affected other functions.

So if you make a change to a common function (a function used by different classes) you run the whole test suite to ensure that no other function is negatively affected by this change. Like Gurgle says, it isnt a 100% accurate system as it depends on who is writing the tests but it does find a lot of errors before they get released.

IamtheWalrus

Gurgle wrote: »

proper detailed spec.

I've never coded from a spec - it's just details written in a bug collator e.g. JIRA.

IamtheWalrus

It sounds like something that requires project experience to get the hang of and I would be found out if I just coded from online tutorials.

discodowney

IamtheWalrus wrote: »

My current project is an Agile project. Using TDD, do I pick up a story, design what changes are needed then start writing tests, followed by code to pass the test? Is this really how it works or is that the 'ideal' but in practice it's much different?

It depends. A lot of companies have specialised Test Programmers whose job it is to write these tests and ensure they all pass. If not they analyse the failure and talk to whoever implemented the changes.

Some places the developer does the testing as well. In this case usually a user story will involve tasks to implement the code and write the test. In practice, Ive found most people do the implementation first.

discodowney

Id besurprised if any job was expecting a student (im assuming you are one) to have been involved in TDD for a college project. The time just isnt there for that. Its generally manual testing for them.

IamtheWalrus

discodowney wrote: »

In practice, Ive found most people do the implementation first.

Is this true? Do managers accept this?

I'm not a student. I'm working on a real project without TDD. I want to put TDD on my CV but don't want to out it on there if I genuinely won't be able to bluff it.

I'm also afraid of moving onto an Agile, TDD project that does pair Programming. If I'm pairing, will it be obvious to my 'pair' that I don't have commercial experience in TDD?

Colonel Panic

Are there unit tests for the existing functionality? If not you will need to add them, as in do you understand the domain, or a subset of it, well enough and could you do it (probably in your free time) in a realistic timescale?

Writing failing tests first then adding functionality is all well and good, but without coverage of the rest of the system you are modifying, you have no idea of knowing what else you've broken.

For what it's worth on C++ projects here in work we don't as a rule do unit tests or TDD, but on projects I'm responsible for, I've taken chunks of business logic and other subsystems and applied unit tests to them. Now new features get a test written first. Doing this took a long time for even a modestly sized application.

I didn't learn how to do this on the job, I applied TDD at the same time as I was learning ASP.Net MVC.

IamtheWalrus

Colonel Panic wrote: »

Are there unit tests for the existing functionality? If not you will need to add them, as in do you understand the domain, or a subset of it, well enough and could you do it (probably in your free time) in a realistic timescale?

Writing failing tests first then adding functionality is all well and good, but without coverage of the rest of the system you are modifying, you have no idea of knowing what else you've broken.

For what it's worth on C++ projects here in work we don't as a rule do unit tests or TDD, but on projects I'm responsible for, I've taken chunks of business logic and other subsystems and applied unit tests to them. Now new features get a test written first. Doing this took a long time for even a modestly sized application.

I didn't learn how to do this on the job, I applied TDD at the same time as I was learning ASP.Net MVC.

Yes, we do 'test after development'. I write my code, then unit test it to prove it works. This goes against the TDD ethos. The tutorials I have followed follow a very specific pattern (write failing test, write code to make it pass, refactor and repeat). To me it sounds very time consuming and idealist. So I'm wondering how it is actually implemented on commercial projects.

Maybe I'm obsessing too much on TDD. Maybe it's something that is something that is casually done in projects and my current knowledge is enough to claim I've got commercial experience of it.

Colonel Panic

I'm open to being wrong, but I don't think you can do pure TDD for the reasons you mention. It's a time consuming endeavour and it's hard to account for that time with management. I'm always wary of TDD because I think there's a cargo cult aspect to it but like everything, it's got a time and a place.

One suggestion I would make about the time consuming aspect is to write code in your tests even if that code doesn't exist yet. It's annoying because your autocomplete tools will start to break down (there's a keystroke in Visual Studio to disable this) but once you've written the non compiling, and therefore failing test, you can use refactoring tools to fill in the stubs of the functionality you want to write. I consider this a major advantage of TDD because it helps focus on the public interface you are dealing with first, and get down to implementation after.

Do you consider yourself good at writing unit tests? Not the test code itself, but what gets tested? If so, you could just focus on that if it came up in an interview and put down writing unit test on your CV.

markpb

Colonel Panic wrote: »

I'm open to being wrong, but I don't think you can do pure TDD for the reasons you mention. It's a time consuming endeavour and it's hard to account for that time with management.

Unless you're writing very simple software, I don't think that TDD will take any more time to write good code than TAD or any other method. Will it take more time than basic testing or no testing - absolutely but you'll pay in the long run.

If you work for a company where management are getting involved (negatively) in how you do your testing or refusing to schedule enough time to test properly, you need to either argue with them or go work for a different company.

I've used TDD on a few of our projects here, mostly where I knew that specific methods or components would be tricky and have a lot of different flows (decoding protocols, etc) and it was invaluable. I wrote some very simple tests, then wrote the code. As I discovered new edge cases that weren't handled, I was able to add tests and update the code, safe in the knowledge that all my other edge cases weren't being broken.

Colonel Panic

Yeah, perhaps. Maybe me next attempt at TDD will take less time if I can change my thinking and resist the urge to bang out a new feature in a system I know well then create a unit test. "Simple" is a subject term though. Simple in terms of the amount of features to write tests for, or the functionality you are testing?

Management usually get involved when it comes to deadlines and features but that also includes the time taken to overhaul development processes, set up new build systems, switch to TDD, switch to git or Mercurial and for them it's a balance between commercial demands and the technical side of things. It's not about just leaving if that end of things doesn't work out because you can't go anywhere where it isn't an issue.

markpb

Colonel Panic wrote: »

Management usually get involved when it comes to deadlines and features but that also includes the time taken to overhaul development processes, set up new build systems, switch to TDD, switch to git or Mercurial

There's no need to do any of that. TDD is just about writing tests, writing code and then running the tests. Nothing more. It has no relationship to the build system or the repository system. You can make your build system automatically run the tests on check-in but that's not a requirement, it's a nicety. There's no need to switch from anything to git or mercurial, they're nothing to do with the TDD.

Colonel Panic

I'm talking about management getting involved with development processes in general there.

Feathers

IamtheWalrus wrote: »

Yes, we do 'test after development'. I write my code, then unit test it to prove it works. This goes against the TDD ethos. The tutorials I have followed follow a very specific pattern (write failing test, write code to make it pass, refactor and repeat). To me it sounds very time consuming and idealist. So I'm wondering how it is actually implemented on commercial projects.

Why do you think it's more time-consuming to write tests first? The only aspect I'd consider time-consuming is when I have to question the spec/ make design decisions, but doing this upfront saves on debugging down the line & bugs are cheaper the earlier you catch them.

TrueDub

Feathers wrote: »

Why do you think it's more time-consuming to write tests first? The only aspect I'd consider time-consuming is when I have to question the spec/ make design decisions, but doing this upfront saves on debugging down the line & bugs are cheaper the earlier you catch them.

The bit I've bolded in the quote above is the essence of TDD and ATDD (acceptance TDD). if ou find a bug early, it's much much cheaper to fix. Also, if you examine the requirements ahead of time, you write tighter, cleaner code.

TDD is a mindset, once you're into it it's almost impossible to get out, and that's a good thing. A full suite of unit tests provide a really good comfort blanket for future changes.

Sparks

Feathers wrote: »

doing this upfront saves on debugging down the line & bugs are cheaper the earlier you catch them.

It's a wonderful argument, and one that you can usually get people to listen to for a new project.

Trying to bolt TDD (or even just plain unit testing) onto a legacy project with that argument leads inevitably to the line from sales of "you're spending N man-years worth €X; what feature does this result in that we can use to generate more revenue? None? Door's over there." Arguing that you can reduce costs in a quarter a year or so from now, when quite a few of those who signed off on the decision to do so could have moved on (funny how these sales types have such a higher churn rate than the people actually building the things they're selling), doesn't seem to work as well as any argument that increases this quarter's numbers, even if it screws over a quarter a year or so from now - after all, that'll be Some Other Guy's Problem...

Depending on the size of the project, I've come to think that TDD isn't an idiom that can be used in industry without a management team that believe you can make no profit for a year to pay down technical debt (if you see such a management team, let someone know that you've spotted a highly endangered species, would you?).

markpb

Sparks wrote: »

Trying to bolt TDD (or even just plain unit testing) onto a legacy project with that argument leads inevitably to the line from sales of "you're spending N man-years worth €X; what feature does this result in that we can use to generate more revenue? None? Door's over there."

I can't argue with that but I think developers need to stand up for themselves. If a dev manager asks for a time estimate for a piece of work, that estimate should include a reasonable amount of testing built in. Unless they're a complete micro-manager (and I know there are some out there), there should be no problem. In some cases, I wouldn't even both explaining that I'm including unit testing in the estimate.

Of course if you go overboard and want to add unit testing for every part of an existing project when you're asked to make a small change, you're just bringing trouble on yourself.

Sparks

markpb wrote: »

I can't argue with that but I think developers need to stand up for themselves.

Whoa, whoa, stall that digger there a moment.
Stand up for ourselves? What?

We work for companies that sell products. We give our professional opinion on how to do the job, and if management choose to do something that sends it to the wall despite that? Not. Our. Problem. We quit and go work elsewhere (and in our industry, usually with an accompanying salary hike). That's the gig. Doing anything else is getting emotionally invested in a computer product, which (a) is kindof creepy, that's what your family is for; and (b) is absolutely guaranteed to mess you up in the long run.

What I'm saying is that with a legacy system, trying to make the argument to management for TDD or even plain old Unit Testing is a long, long, long way from easy or simple because the fact that it's a better way to build something in the long run is irrelevant to Sales or Marketing, who don't care about the internals, but only about what externally visible things they can use to sell product, and who operate on infuriating short timescales.

Colonel Panic

Sparks wrote: »

We work for companies that sell products. We give our professional opinion on how to do the job, and if management choose to do something that sends it to the wall despite that? Not. Our. Problem.

Well put. This is something it took me a few years to come to terms with, I have to admit. You do the best you with what you get. If the pros outweigh the cons, move on, but you certainly can't expect any environment to be some sort of computer science shangri-la!

Feathers

Sparks wrote: »

Feathers wrote: »

doing this upfront saves on debugging down the line & bugs are cheaper the earlier you catch them.

It's a wonderful argument, and one that you can usually get people to listen to for a new project.

Trying to bolt TDD (or even just plain unit testing) onto a legacy project with that argument leads inevitably to the line from sales of "you're spending N man-years worth €X; what feature does this result in that we can use to generate more revenue? None? Door's over there." Arguing that you can reduce costs in a quarter a year or so from now, when quite a few of those who signed off on the decision to do so could have moved on (funny how these sales types have such a higher churn rate than the people actually building the things they're selling), doesn't seem to work as well as any argument that increases this quarter's numbers, even if it screws over a quarter a year or so from now - after all, that'll be Some Other Guy's Problem...

Depending on the size of the project, I've come to think that TDD isn't an idiom that can be used in industry without a management team that believe you can make no profit for a year to pay down technical debt (if you see such a management team, let someone know that you've spotted a highly endangered species, would you?).

I agree the ideal is having full test coverage, but there's no reason you can't do TDD for the individual method that you need to refactor, provided its properly OO.

If you're going into legacy code, you a bug or a feature request. If you've a feature request, you're going to have to regression test areas that interact with the code you're touching. TDD is getting some of that effort in up front.

If you've a bug, just write a test that proves the bug exists, then fix the code to make the test pass - you now have one more regression test against that area for the next change. You'll rarely be working on legacy code to change one single bug So it ends up benefiting the rest if your work now, not just in a year's time.

I don't think it needs to be all or nothing.

Sparks

Colonel Panic wrote: »

This is something it took me a few years to come to terms with, I have to admit.

I've found two things help enormously though. There's doing your own stuff as a hobby (though not everyone can find the time); and there's this:

IamtheWalrus

Thanks all for taking part in this debate. I've been so busy to read all posts but I will this week.

Thanks again.

markpb

Sparks wrote: »

We work for companies that sell products. We give our professional opinion on how to do the job, and if management choose to do something that sends it to the wall despite that? Not. Our. Problem.

I disagree. Almost every company will want their developers to get the job done as quickly as possible, in the same way that companies want buildings, ships, cars or aircraft built quickly. It's up to the professionals involved to do the best job they can with what's available. If they succumb to the pressure to deliver as quickly as possible and at any cost, they're only doing themselves and their profession a disrespect.

Would you say the same about builders throwing up buildings as quickly as possible because the developer wanted it? What respect is there for builders in Ireland now?

Sparks

markpb wrote: »

I disagree. Almost every company will want their developers to get the job done as quickly as possible, in the same way that companies want buildings, ships, cars or aircraft built quickly.

Exactly.
And since the tests can't be seen by the customer, Sales tends to think that they're a waste of expensive engineering time. And it wouldn't be unusual to hear an argument that boils down to "why are we paying for engineers to write code that the customer never sees and whose only role is to spot the engineers fouling up?". To you or me or the rest of the posters here, that's a dumb-ass argument for them to make; to every salesperson out there it's perfectly logical, so long as your top priority is this quarter's figures.

If they succumb to the pressure to deliver as quickly as possible and at any cost, they're only doing themselves and their profession a disrespect.

That's assinine. You give your professional opinion as to how best to do the job, yes; but if management (or the client) says "fine, now do it this way instead", then you have precisely two options; accept your salary and do the job they want; or quit on principal.

The latter doesn't pay many bills. That might not be as important when you don't have a family to support I suppose; but then again, the latter is often red-flagged by some companies when hiring.

tl;dr : Management pays the piper and gets to call the tune; that's a big part of what being a professional means.

Would you say the same about builders throwing up buildings as quickly as possible because the developer wanted it? What respect is there for builders in Ireland now?

Lots. Your average bricklayer isn't being held up as the cause of the economic collapse; the 100 or so developers who gave them their orders, on the other hand, are the ones being hauled into court over debacles like Priory Hall.