I have taught TDD a lot. I've even gotten old-timer COBOL programmers excited about it. These concepts help most:
1) Your unit tests should describe the behavior of the code. If you start with only the unit tests of the system, you should be able to rebuild the code and the system will behave the same as with the original code.
2) Unit tests should be quick to write and easy to understand. When your unit tests are complicated, your code needs refactoring, decoupling, and/or architecture needs refining.
3) Name tests well, to make them manageable. I prefer snake case: "()"
4) Red/Green/Refactor is important. All tests MUST initially fail. If they don't, you either have a duplicate test or there is a bug in the code. I have caught bugs a few times, via initial Green tests.
Oh, that changes everything. I understood TDD as starting with a test case that fails its assertions only and getting the function set up properly beforehand (mocks, injected dependencies, etc.) was the difficult part. If it's just getting the task requirements in as test cases at the start, that's what every single TDD explanation is missing.
Oh, that is terrible news! I highly recommend looking into Roy Osherove's book, "The Art of Unit Testing", which is fantastic. Bob Martin also has some good TDD information, but I recommend reading his "Clean Code" book to get a look at how to better organize code, which is essential for good TDD. I genrally start my students (generally very junior developers) with these two books.
You can immediately find beneficial help by looking up some "Red Green Refactor" kata videos. Pluralsight may also have something useful.
TDD is a massive shift in thinking for most people. It requires practice and patience. It took me about 5 days before the concept clicked, and I suddenly understood the intent. Everything suddenly made sense and I saw the dangers of traditional practices.
This forced me to learn decoupling architectures and mocking frameworks. My code vastly improved.
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.
I have taught TDD a lot. I've even gotten old-timer COBOL programmers excited about it. These concepts help most:
1) Your unit tests should describe the behavior of the code. If you start with only the unit tests of the system, you should be able to rebuild the code and the system will behave the same as with the original code.
2) Unit tests should be quick to write and easy to understand. When your unit tests are complicated, your code needs refactoring, decoupling, and/or architecture needs refining.
3) Name tests well, to make them manageable. I prefer snake case: "()"
4) Red/Green/Refactor is important. All tests MUST initially fail. If they don't, you either have a duplicate test or there is a bug in the code. I have caught bugs a few times, via initial Green tests.
Is red a test failure or an error, or both?
Compiler / Interpreter errors = RED.
It is also red when the test simply fails.
Oh, that changes everything. I understood TDD as starting with a test case that fails its assertions only and getting the function set up properly beforehand (mocks, injected dependencies, etc.) was the difficult part. If it's just getting the task requirements in as test cases at the start, that's what every single TDD explanation is missing.
Oh, that is terrible news! I highly recommend looking into Roy Osherove's book, "The Art of Unit Testing", which is fantastic. Bob Martin also has some good TDD information, but I recommend reading his "Clean Code" book to get a look at how to better organize code, which is essential for good TDD. I genrally start my students (generally very junior developers) with these two books.
You can immediately find beneficial help by looking up some "Red Green Refactor" kata videos. Pluralsight may also have something useful.
Love those points, they touch the crux of the matter!
You're spoiling the fun of the next post 😁
Oops!
TDD is a massive shift in thinking for most people. It requires practice and patience. It took me about 5 days before the concept clicked, and I suddenly understood the intent. Everything suddenly made sense and I saw the dangers of traditional practices.
This forced me to learn decoupling architectures and mocking frameworks. My code vastly improved.