To summarize:
1) Write a failing test 2) Make it pass as quickly as possible 3) Repeat and refactor as necessary
1. [The Pragmatic Programmer](https://pragprog.com) 2. Martin Fowler's [Refactoring Book](https://martinfowler.com/books/refactoring.html) 3. Kent Beck's [Test Driven Development: By Example](https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/...) 4. [Thinking in Systems: A Primer](https://www.amazon.com/Thinking-Systems-Donella-H-Meadows/dp...) 5. [Zen Mind, Beginner's Mind: Informal Talks on Zen Meditation and Practice](https://www.amazon.com/Zen-Mind-Beginners-Informal-Meditatio...) 6. [Pragmatic Thinking and Learning: Refactor Your Wetware](https://www.amazon.com/Pragmatic-Thinking-Learning-Refactor....)
Robert C. Martin, Clean code: https://www.amazon.com/Clean-Code-Handbook-Software-Craftsma...
Vaughn Vernon, various: https://vaughnvernon.co/?page_id=168
Steve McConnell, Code Complete: https://www.amazon.com/Code-Complete-Practical-Handbook-Cons... 2
Clean coder: https://cleancoders.com/ videos
Hunt and Thomas, The Pragmatic Programmer: https://www.amazon.com/Pragmatic-Programmer-Journeyman-Maste...
Hitchhiker's Guide to Python: https://docs.python-guide.org/
Dustin Boswell The Art of Readable Code: https://www.amazon.com/Art-Readable-Code-Practical-Technique...
John Ousterhout, A Philosophy of Software Design: https://www.amazon.com/Philosophy-Software-Design-John-Ouste... This one looks particularly interesting, thanks AlexCoventry!
Kent Beck, Test Driven Development: https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/...
Dan Bader, Python Tricks: The Book: https://dbader.org/
Ian Sommerville, Software Engineering: https://www.amazon.com/Software-Engineering-10th-Ian-Sommerv...
Svilen Dobrev, various: http://www.svilendobrev.com/rabota/
- behind any given reason, there is a complex network of real reasons. You don't need to second-guess any decision/order/suggestion, but it helps understanding.
- most user stories / user requests are raw diamonds waiting to be polished. ("What do they really want me to solve")
Essential reading list:
- Clean Coder and Clean Code https://www.amazon.com/Clean-Code-Handbook-Software-Craftsma... https://www.amazon.com/Clean-Coder-Conduct-Professional-Prog...
- Test Driven Development by Kent Beck https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/...
Yep. Uncle Bob is one person, too. tl;dr Think for yourself and don't listen to somebody just because they hurt your feelings.
> To pick a topical example: Is TDD hard in Rails apps because TDD is dead or because Rails makes TDD hard?
This is a misrepresentation of what DHH has said [1], which is that strict adherence to TDD can make your designs worse:
> Over the years, the test-first rhetoric got louder and angrier, though. More mean-spirited. And at times I got sucked into that fundamentalist vortex, feeling bad about not following the true gospel. Then I'd try test-first for a few weeks, only to drop it again when it started hurting my designs.
> Used as a hammer to beat down the nonbelievers, declare them unprofessional and unfit for writing software. A litmus test.
If you watch the conversations between DHH, Martin Fowler, and Kent Beck, it seems to me that they all agree: testing is good, test-driven design can be bad, and mocking everything is bad [2][3].
I took some time last week to re-read Uncle Bob's book, Agile Software Development, Principles, Patterns, and Practices [4], and Kent Beck's book on TDD [5]. There was a huge difference: Uncle Bob focuses on test-driven design, while Kent Beck focuses on test-driven development. Uncle Bob claims that test-driven development (especially through mocks) universally improves your design, because it reduces coupling and enables refactoring. Kent Beck talks about productivity, certainty, refactoring, and documentation. Uncle Bob says most of those things are just a side-benefit: the real point of TDD is decoupled design.
Uncle Bob's other book, The Clean Coder [6], berates people who do not strictly adhere to test-driven design: if you don't do it, you are unprofessional (he mentions this repeatedly). He says that TDD being universally good is a fact, and anybody who says otherwise is just ranting.
> Nowadays, however, they are just rants. The bottom line is that TDD works, and everybody needs to get over it.
> TDD is the professional option.
> It could be considered unprofessional not to use it.
The bottom line is that developers should listen to each opinion and use their head. Don't be hurt when somebody calls you unprofessional for not following the One True Gospel™ and mindlessly adopt practices. Don't be hurt when somebody says that mindlessly following those practices is counterproductive. Using your head is about the most professional thing you can do.
[1] TDD is dead. Long live testing. http://david.heinemeierhansson.com/2014/tdd-is-dead-long-liv... [2] Mockists Are Dead. Long Live Classicists. http://www.thoughtworks.com/insights/blog/mockists-are-dead-... [3] Is TDD Dead? https://www.youtube.com/watch?v=z9quxZsLcfo [4] Agile Software Development: Principles, Patterns, and Practices. http://www.amazon.com/Software-Development-Principles-Patter... [5] Test Driven Development By Example. http://www.amazon.com/Test-Driven-Development-By-Example/dp/... [6] The Clean Coder. http://www.amazon.com/Clean-Coder-Conduct-Professional-Progr...
Edit: For those that don't know Kent Beck is basically the godfather of TDD.
[1] http://www.amazon.com/Test-Driven-Development-By-Example/dp/...
[2] http://pragprog.com/screencasts/v-kbtdd/test-driven-developm...
From "Test Driven Development" by Kent Beck, published 2002: http://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0...
Here are some excerpts:
"What test do we need first? Looking at the list, the first test looks complicated. Start small or not at all. Multiplication, how hard could that be? We'll work on that one first."
The examples like this that were provided were of trivial methods. Trivial can be subjective, but, to me, methods whose bodies are almost always 2-5 lines long, not counting calls to other trivial methods, which may account for maybe another 2-3 additional lines, are basically trivial. It's one thing when you really don't need that much code, but it's another when you have classes upon classes upon classes upon classes, etc. to do something that could be OO and be in two classes with 1/2 as many lines and still be clear.
"Do these steps seem small to you? Remember TDD is not about taking teeny-tiny steps, it's about being able to take teeny-tiny steps. Would I code day-to-day with steps this small? No. But when things get the least bit wierd, I'm glad I can."
This is what Kent meant, but few of us picked up on it, per the first comment to his answer in your example from S.O. and per my experience.
I'm not blaming Kent, Ron, etc. or even saying that they are or were wrong. But, the commonly understood epitome of TDD used to be 100% test coverage and methods for just about everything. Those in the know said more like 60% was better overall but that was not really "true TDD". The implication of 100% "trivial" methods is more overhead for method calls (minor cost, depending, but can be cumulative, increase/decrease call stack size more quickly, which is inefficient), a large number of entry points (more stuff can be null/nil, cause NPE's or need checks if you don't know what is going to call it later, though that can be mitigated somewhat), and just generally too many LOC.
With a testing framework, you won't waste time rolling your own. For Java, you could start with JUnit.
TDD is a formalized approach to writing test functions as you work, which you already do, while simultaneously designing your code. There are many sources on it around the internet, but Kent Beck's book took the magic out of it (a good thing) for me: http://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0...
Of course, there are many other specific techniques you can use to test that your algorithms do the right thing, all dependent on what you've made. Regardless, I try to make sure that the a real user gets their hands on an up to date build as often as possible, and they're sure to show me all of the ways that my software is technically excellent, yet in no way solves their actual problem.
http://www.amazon.com/Test-Driven-Development-Addison-Wesley...
By Kent Beck, right?
[1] https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/...