Yeah, you kind of have to do this.  Whether you are doing TDD or 'just' unit testing, if you are taking it seriously, it kinda defeats the purpose to have as a separate task.

This could happen if people confuse unit tests with integration tests.  Recently worked on something where all code was required to be 'unit tested' but they really meant it had to have undergone some sort of integration testing.

Exactly.  If you do not test now, you definitely won't test later and that's a lazy ass approach to development.  If you buy into something like this then you do not buy into testing at all.  So I say your scrum master better start to get a clue.

I can't imagine anyone going through their code at the end and then creating unit tests.  What's the point of that?  You build testing and quality into the project as you go.   The whole point in testing is that you get immediate feedback and results which benefits the entire team as you build out a project together!

Here's a question though.  Do you create a test after each method created in a class or create the tests for all methods of a class after the class is technically done?

So is it on a per method basis or per class basis that you should create your tests.  Where are the start and stop points?

Exactly right attitude. Might want to also point out the productivity gains one gets when one writes a test, then writes the code so that the test compiles. This kind of thing flushes out all sorts of bugs early in the process.

Amen brother Derik!  As a test manager, one of the things I struggle with sometimes is having good visibility into which features have good unit pre-checkin tests and which don't. I've tried having devs track tests as tasks, and more often than not, it drives exactly the behavior you describe. You'll see anti-behaviors like devs declaring "code complete" and then moving on to start writing tests. Inevitably, pressure comes for them to start working on the next feature, so they shortcut testing and just assume the testers will pick up their slack. Then they gripe at the testers for taking so long to get thru testing, build up a backlog of bugs and the death spiral continues.

Doing what you describe takes an up front commitment from the dev manager and accountability on the devs part for doing the right thing. When you reach that point and the easy bugs are found by devs before checin, then the test team can operate much more efficiently and focus on the more complex integration scenarios.

Bravo!

This is an important concept to mentor to less experienced developers.  The whole concept of test-first is foreign to many coming out of college with a CS degree.  I found that academic CS in the last decade reinforced point-based thinking.  I had to unlearn many things to adopt lean concepts and TDD into my day-to-day process

Have to admit im only just getting into all this unit testing, we were taught to develop the error handling with every method, and "extreme programming (XP)" Then again that was writing games in C/C++; I find webdevelopment (where I am) tends to be big job, very short period of time; testing occasionally is the thing that gets sacrificed for the "well it seems to work" approach.