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 entirely...trust 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.So.is 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.
unit level testing, agile, and refactoring
agile;unit testing;refactoring
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.