Do you apply testing in your side projects?

If it were a side project using technology where I was already familiar with the testing tools, I will. I really like testing in environments I'm familiar with. But, for whatever reason, testing tools take me forever to pick up, so I might forego it in low-risk side projects.

I've never done formal testing (still a student), but I've always, always tested as I went and before any "version" updates (or what would be the equivalent of if I was versioning with numbers, etc). Maybe it's because I learn best by breaking things or because of my math background where I helped too many students figure out why their proofs weren't valid (spoiler: using "2" as one of your test numbers is almost always the wrong choice because it does weird stuff) or because I always want to figure out the holes in something, but I've always just sort of done it reflexively.

I'm working on a side project now and as I go I either make notes of things to check later or I go "Hmmm, I wonder if ABC breaks it... yup, yup it does. OK, is that a case I didn't account for and should have in the code, or is there an error somewhere?" and then I dig around and adjust.

I've never used tools to do it, though. Maybe that'll be one of my winter break detours...!

I actually like to be more TDD-focused on side projects — it’s an opportunity to flex my testing muscles and “practice” for work.

There’s obviously a place for hacking and rapid prototyping though. I usually throw together a v1 to force myself to clarify what’s in my head, then rebuild a v2 with thorough testing and better design decisions.

Yep. I do. But I don't always test the same way. Sometimes I just build a few end-to-end tests to cover the big stuff. Sometimes I build little unit tests to cover edge cases in core code. (I'm not a purist about dividing unit/integration/functional/etc testing.)

The best article I've seen lately on the how & why of testing is Sarah Mei's note on Five Factor Testing. The nutshell is that goals matter. There is no One True Testing Methodology.

My advice: side projects are a chance to learn. Why not use them to learn about testing?

I strive to use a risk assessment to decide what to test. I'll assume the following definition:

risk = chance * effect

For instance, if you have a trivial regex you may not feel the need to test it. But sometimes getting it wrong can really screw things up.

I had this hobby project that works with musical keys for follow-up suggestions while djing. I wrote an import to take data from the djing application including the key I needed. I made a mistake in a regex causing some tracks to be assigned the wrong key.

Both chance and effect were high in this case:

• I know that often enough regex is not a first-time-right affair, at least for me
• Assigning the wrong key to a track is detrimental for this application.

On top of that the spec consisted of 24 discrete cases. In retrospect, writing out the spec to test that code should've been a no brainer.

I found it rather unsettling to discover that bug. I'm glad I learned this on my hobby project, but I realized I could've made the same mistake if it wasn't.

I try to. I didn't, int the past, and suffered from it when I made changes and broke things. The benefit of testing in side projects is not proving their correctness - it's protecting yourself from accidentally breaking your code.

As for the type of tests - I prefer integration tests. I think unit tests are overused - they are good for library code, but when you start to need to mock everything their RoI drops and it's time to move to integration tests.

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 :)

To be honest, most of my side projects don't have any sort of rigorous testing, though I understand I could benefit a lot from it.

However, I always unit test my APIs. For that I use a testing library that a mentor of mine had developed when he was part of a contracting agency. (github.com/ishmaelthedestroyer/ctrllr)

If you want to get into testing your front-end, I highly recommend watching Fun Fun Functions Testing Series!

Due to only ever being solo or part of very small development teams I never really picked up a great process for testing. I never had that senior dev to guide me down a route of tdd. Due to this, which is of course my excuse, I just don't do anywhere near enough testing as I should. However this is very much on my 2018 list of development areas.

I set up automated testing for rest APIs using restAssured

I always forget to build with testing in mind from the start, and then I suffer the consequences.