Mindset + Skillset + Toolkit = Success
The Art of Unit Testing: with examples in C
This is not a bad book. If you knew nothing about writing automated tests, this book would OPEN your eyes. You will learn about fakes and mocks. It doesn't go into the Moq framework very much. :(
That said this book has problems.
NO WHERE IN THE BOOK DOES IT STATE THAT THE WHOLE POINT OF WRITING THESE TESTS IS TO ENSURE THAT THE SOFTWARE WORKS.
That is pretty obvious, but no where does it state this. That is the ENTIRE POINT OF HAVING AUTOMATED TESTS!!!
That said the focus is on unit tests. Unit tests are great... But...
Do not write tests for the sake of writing tests, that will get you NO WHERE!
WHAT IS A UNIT TEST?
If you want to create a great internet debate on reddit or any other forum... Ask "What is the difference between a unit test and an integration test?". Don your internet flame suit.
I got tired of debating around this. I don't care what kind of test it is. The tests need to make sure the software works. So now I got fast tests and slow tests. Which ones are they unit or integration? I don't care. Make everything green before releasing the thing.
MAKE SURE THE SOFTWARE WORKS (THAT IS WHAT IS IMPORTANT)
The problem with Unit Tests
Using the googley definition they are small and test amounts of code with no external dependencies.
So maybe an AddTwoNumbers(int x, int y)...
Testing that is great, you can do 90% code coverage of everything via unit tests... What happens when they are intergrated together? Do they still work? Do you meet your acceptance criteria?
KNOWING HOW CODE EXECUTES IN ISOLATION IS ONE THING, KNOWING HOW IT WORKS WITH OTHER CODE IS SOMETHING ELSE
You need to write tests for all paths. YES, this includes the database. From my own experience defects come out of things where there were no tests. That means Unit Tests, Integration, E2E tests. What you call them doesn't matter you need tests to make sure the software works!
HOW DO I GET BETTER AT WRITING TESTS...
By writing more tests. Seriously. Write more tests. If you think something isn't testable... Before refactoring it, walk away and think about it again. Everything is testable.
Also try to make your tests repeatable!