A few years ago, I interviewed for a job, and one of the developers said "we try to do TDD here". So my first project on that job I tested a lot. But it turned out that there was no team culture of unit testing, and it was just this one developer who was into unit testing. In fact, I had put so much effort into testing that I became the "unit testing guy" for a while.
So TDD in a job posting might just be something they threw on there, and it's common for not everything listed to be a hard requirement.
I've never done TDD in its full form, but there are cases where writing the tests first helps. A self-contained class where you know the interface up front, and it seems to help when fixing a bug to write the tests to reproduce the bug before fixing it.
There are arguments either way for TDD. David Heinemeier Hansson had a good RailsConf keynote that I've adopted as my philosophy of testing: The level of testing should be a function of the level of confidence needed for a particular piece of software. Test the things that you think might break, test the application as a whole, and test the things that have broken before, but don't go overboard, because testing a too granular a level can make it hard to refactor. And prefer integration tests over unit tests (this one is iffy, because integration tests can be slow).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
A few years ago, I interviewed for a job, and one of the developers said "we try to do TDD here". So my first project on that job I tested a lot. But it turned out that there was no team culture of unit testing, and it was just this one developer who was into unit testing. In fact, I had put so much effort into testing that I became the "unit testing guy" for a while.
So TDD in a job posting might just be something they threw on there, and it's common for not everything listed to be a hard requirement.
I've never done TDD in its full form, but there are cases where writing the tests first helps. A self-contained class where you know the interface up front, and it seems to help when fixing a bug to write the tests to reproduce the bug before fixing it.
There are arguments either way for TDD. David Heinemeier Hansson had a good RailsConf keynote that I've adopted as my philosophy of testing: The level of testing should be a function of the level of confidence needed for a particular piece of software. Test the things that you think might break, test the application as a whole, and test the things that have broken before, but don't go overboard, because testing a too granular a level can make it hard to refactor. And prefer integration tests over unit tests (this one is iffy, because integration tests can be slow).