Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

This question already has an answer here:

I'm working on a very agile development system, a small number of people with my doing the vast majority of progaming myself.

I've gotten to the testing phase and find myself writing mostly functional level testing, which I should in theory be leavning for our tester (in practice I don't our tester to detect and identify defects enough to leave him the sole writter of functional tests). In theory what I should be writing is Unit level tests.

However, I'm not sure it's worth the expense. Unit testing takes some time to do, more then functional testing since I have to set up mocks and plugs into smaller units that weren't design to run in issolation. More importantly, I find I refactor and redesign heavily-part of this is due to my inherriting code that needed heavy redesign and is still being cleaned up, but even once I've finished removing parts that need work I'm sure in the act of expanding the code I'll still do a decent amount of refactoring and redesign. It feels as if I will break my unit tests, forcing wasted time to refactor them as well, often due to unit test, by definition, having to be coupled so closely to the code structure. it worth all the wasted time when functional tests, that will never break when I refactor/redesign, should find most defects? Do unit tests really provide that much extra defect detetection over through functional? and how does one create good unit tests that work with very quick and agile code that is modified rapidly?

ps, I would be fine/happy with links to anything one considers an excellent resource for how to 'do' unit testing in a highly changing enviroment.

edit: to clarify I am doing a bit of very unoffical TDD, I just seem to be writing tests on what would be considered a functional level rather then unit level. I think part of this is becaus I own nearly all of the project I don't feel I need to limit the scope as much; and part of it is that it's daunting to think of trying to go back and retroactively add the unit tests needed to cover enough code that I can feel comfortable testing only a unit without the full functionality and trust that unit still works with the rest of the units.

share|improve this question

marked as duplicate by Matthew Flynn, gnat, MichaelT, GlenH7, Yannis Oct 23 '13 at 10:52

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

Consider putting your main question in the title and using headings and bold test to highlight main points. Makes in easier and more enjoyable to help you. – Brenden Oct 22 '13 at 19:08
up vote 5 down vote accepted

Ah... you're most definitely not doing TDD. TDD is Test-Driven Design; in particular, it's writing the specifications (aka tests) first. What you're doing is writing tests (which is fine, and normally quite useful - after all, we need to test the code, it's just that most of us are fine with doing that manually).

As for unit tests vs functional tests; in my view, the fact that you "refactor and redesign heavily" is the main benefit of unit tests. I like that the resulting code is designed better than it was when I started. Whether that effort is justified is, unfortunately, rather subjective.

I wouldn't focus on "trying to go back and retroactively add the unit tests needed to cover enough code"; try adding tests around pieces of functionality that you feel are complicated enough to warrant it. I have a particular example where I had to add tests because a view in the project I'm working on had a lot of logic in it for displaying the correct time depending on the market and time-zone. It wasn't TDD - the production code was already there - but I wanted to make sure that it works correctly in various cases I could think of. I do not believe that those tests will need to be changed for anything short of a changing business requirement.

I will end by pointing to the obligatory "Working Effectively with Legacy Code" reference.

share|improve this answer
This is a good answer. Test first, then write your code. It seems slower when you think about it, it is definitely faster when you implement it. The other opportunity for adding tests is when you find bugs- then you can add a test case for the bug, write the fix and be confident the bug won't turn up again later as a nasty surprise. – glenatron Oct 22 '13 at 15:10
TDD is, in the long run, A LOT faster than old-style "test when you feel it". Because it ensures everything you write is covered and written in a testable way – Guillaume Oct 22 '13 at 16:31
@Guillaume absolutely agreed. Robert Martin has some nice talks on Youtube on the subject. (To paraphrase: write a small test, write a bit of code... it's stupid! But five minutes ago, ALL your code was working.) – Marcel Popescu Oct 22 '13 at 16:38
Yes I'm a big fan of Uncle Bob's talks and books – Guillaume Oct 22 '13 at 21:03

Not the answer you're looking for? Browse other questions tagged or ask your own question.