Reddit reviews xUnit Test Patterns: Refactoring Test Code

We assign mentors (usually the more experienced team members, but can vary depending on project and resourcing requirements) to new guys who will help them get to grips with things like our methodologies, coding standards, etc.

If we end up with a team consisting of a lot of guys without TDD experience (rare, but my teams can vary depending on other projects/resources within my company), we'll occasionally run TDD workshops where one of my senior guys or myself will go through a fill worked example of TDD, and then point the new guys in the direction of suitable resources so they can self learn (although we support them as much as required).

In terms of resources, there are a number of books we have on our internal "recommended reading" list:

1. The Clean Coder : A Code Of Conduct For Professional Programmers by Robert C. Martin (http://www.amazon.com/The-Clean-Coder-Professional-Programmers/dp/0137081073). This is a good book for developers in general, but has a good section on TDD.
   
   
2. Test Driven Development : By Example by Kent Beck (http://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0321146530/ref=sr_1_1?s=books&ie=UTF8&qid=1458766760&sr=1-1&keywords=kent+beck). Kent Beck is one of the leading proponents of TDD, and this is well worth a read. I find that the fact the text is example driven really helps our developers relate TDD principals to actual real life situations.
   
3. xUnit Test Patterns : Refactoring Test Code by Gerard Meszaros (http://www.amazon.com/xUnit-Test-Patterns-Refactoring-Code/dp/0131495054). This is a bit more advanced and goes above why and how to use TDD - in fact, it's not specifically about TDD, but rather just unit tests in general. However, it explains ways and patterns that can be used to design your code and your tests correctly in order to produce quality tests.
   
   There's a lot of information on the web, but I find sometimes books are just the best source.

My opinion:

On one hand, you should learn what you can do with the tools
Mocking framework
Testing framework
Various other tools / techniques / patterns (thinking about test data builders, object comparison, code coverage...)
This part is not necessarily difficult. The basic mechanics of moq and xunit can be learned in a couple of days, maybe less

Then, on the other hand, you must learn proper and useful ways to use those tools to have meaningful tests. And this is harder, the job of a lifetime of testing. I would encourage you to:
Check blogs of people like uncle Bob
Peek into how other people in successful projects do testing. Enter github, and look for repos
Books. I can recommend you this one: https://www.amazon.com/xUnit-Test-Patterns-Refactoring-Code/dp/0131495054

can't go wrong with the RSpec book as a great starting point. great intro to cucumber too.

xUnit Test Patterns: Refactoring Test Code is a good read as well, though slightly more academic. a good substitute if you don't have the time is writing a shit load of tests and fully understanding what your assertions do.

also, stop testing the framework. nothing screams "amateur hour" like this:

describe Message do

it { should respond_to(:name) }
it { should respond_to(:email) }
it { should respond_to(:body) }
it { should respond_to(:phone) }
it { should respond_to(:subject) }
it { should respond_to(:sweet_honey) }

end

I've enjoyed the xUnit test patterns book. It's all about fundamentals that span languages and frameworks.

http://www.amazon.com/gp/aw/d/0131495054

xUnit Test Patterns: Refactoring Test Code

I liked this book: https://www.amazon.com/xUnit-Test-Patterns-Refactoring-Code/dp/0131495054

The right level of testing depends on you and on your program. Tests that exercise your entire program with no mocking, doing exactly what it's supposed to do in the environment that it's supposed to do it, are pretty much the gold standard, but there are some things that are harder to test like that, and also such tests tend to be a bit slower to run than smaller tests. Tradeoffs everywhere.