I've noticed that I've rarely ever stuck to a pure-TDD strategy. Recently I started writing tests for as much code as I write, including side projects. But I don't really follow TDD very often. I do document expected behavior first, but I've found that various tools like IDEs rarely play nice when tests are written for code that doesn't exist yet.
Quick answers to the bullet-point questionnaire:
Yes, in recent times.
Yes, absolutely. Side projects are for learning. Learning how to write tests is as important as learning how to write code.
Definite benefits. Tests give me this sense of confidence in the code that I've written. If something doesn't work as expected, I know it's a case of something that I haven't covered in the tests, not something I've messed up in the code under coverage.
Definitely more unit tests. This is the way it should be. If you have more integ tests, it's usually a sign that you have too few unit tests.
I use Postman and equivalent clients for REST API testing. I should probably change that to be quite honest. It's a lot better to document the behavior of your application by end-to-end tests that are versioned along with your code.
Hope this helps :)
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've noticed that I've rarely ever stuck to a pure-TDD strategy. Recently I started writing tests for as much code as I write, including side projects. But I don't really follow TDD very often. I do document expected behavior first, but I've found that various tools like IDEs rarely play nice when tests are written for code that doesn't exist yet.
Quick answers to the bullet-point questionnaire:
Hope this helps :)