The idea behind TDD (Test Driven Development) is to write tests first and then write code. I'm not agree with that, at least at the beginning of your career. Let me explain my point
If you're a beginner this approach is so weird, anti-natural, and is hard to get in your first projects. You need to deliver value, you need to write features first and then show your results to your boss or to your customers. For that very same reason I avoided learning testing in the beginning of my career. I think first about features, and then I think on how to test it, not the other way around.
Probably this breaks some fancy development principles, but I don’t care. What you need to care about is to write tests, it doesn't matter the moment you write them, but for me it is more natural to Write Code First and Then Tests. This kind of tests have a name in the community: Test Last Development (TLD)
In Test Last Development time is relatively lower than TDD because of the iterative nature of this last (between testing, coding, refactoring, and learning curve). TLD is better in focusing than TDD where the whole focus will go on the code, and later on automated tests. While in TDD constantly move to and from code and test cases which may decrease the focus.
This article mentions some of the key pros and cons of each of them, and I want to add something else:
- * I’m always working in projects that need to iterate fast, that’s one of the reasons why TDD is not efficient for me
- * Usually, customers or Product Managers don't care about writing tests, they are more interested in spending time fixing bugs and writing new features. It feels like tests don't deliver value to customers. Even so many companies don't appreciate spending time in tests
- * However this scenario changes when the Project Manager is a technical one. He/she knows the importance of tests and always asks for tests. At that moment it is better to think of it as TDD.
- * Test things manually via UI at the beginning. Is the natural way we find bugs or things to enhance. Once the feature is ready, build the tests around it
- * Beginners avoid TDD because it is anti-natural. It feels like a lot of unnecessary complexity. Once you write the feature you’ll know what to test
- * Writing tests sometimes doubles the development time. If you’re working as an hourly freelancer, probably your customer won’t be happy to see testing time on the invoice.
- * You will see the benefits of testing just when the project scale and there are many moving parts or when you need to upgrade versions or avoid changes errors
Now that we know more about testing strategies and principles let's write some tests. From here and now, I'll try to do everything inside a dummy project and show you how to do something there. The steps I’ll follow are:
- 1. Create and empty Rails project
- 2. Configure our test suite
- 3. Create a scaffold
- 4. Write tests
We’ll see that in the next post
Thanks for reading