Nice article. As someone who has been doing some form of TDD for several years, I wish that every tutorial about x framework in y tech came with tests. Besides the obvious advantages of writing tests anyway, tutorials are often written for beginners in y tech which means non-beginners have to skip but if there were tests, these people could easily skip the article and go directly to the tests. Or RTFT as I like to call it.

A nice follow up article would be hooking up a GitHub repo to a coverage tool, something like codeclimate.

I started testing not long ago but frankly I like it. Sure, it isn’t always easy and I am still learning but it’s a nice challenge and my code gets better, and better organized at every step. So I guess it’s a good thing.

Thanks for the article Alicia, and thanks for the links. Those look like the tools I need at the moment. Awesome! :)

This is interesting:

“Recently, the startup I was a part of had to remove large sections of our website. Not just content, but entire pages and functionality. It wasn’t a very pleasant experience, not only for the reason why we had to remove so much of what we had built, but also because it’s the ultimate “I really hope this doesn’t break something else” situation. It was a stressful and tedious effort of triple checking that the things we were removing weren’t dependencies elsewhere. To be honest, we wouldn’t have been able to do this with any amount of success or confidence without our test suite.”

I agree that having automated tests in place is valuable and can give confidence when making any changes to an existing application, however what you choose to test and how you test it will determine how scalable your test writing process is. Its important when adding any features to your process, including the testing, that it is well thought out, and provided in a way that is easy to create, read, update, delete just as much as the code is, or you can have an expensive, or slow build process.

It is also important to have been in a bad code environment or a bad test environment, and experience the difficulty of it, so it can motivate change for improving the process, and influence better technology stack decisions, not just popular ones.

I’m surprised that (automated) regression testing isn’t covered. Is that type of testing accepted as a given, or is my underpowered brain missing the point?