Hi everyone 👋
Yesterday I started to learn more about TTD (test-driven-development) in JS. I checked out Mocha, supertest & assertthat and everything was very easy set up. I wrote some simple test cases (unit + integration) in Node.js, so overall it looked like a very nice strategy to increase the quality of the product/code (overtime). But then I asked myself, why I have never done this before? What kept me back? I always thought, that if you are the only developer of your side project it wouldn't make sense to write those tests because you would lose a lot of time instead of just trying out your idea.
That's why I would like to ask you:
- Do you apply testing in your side projects?
- Does it make sense to you?
- Have you benefit from that, what is your experience?
- Do go more for unit tests or more for integration tests?
- Do you test your REST API in this way or just hit the API by Postman as I do? 😅
Maybe you have some advice for me, let's discuss!
Already, thanks in advance!
Best, Nicho ✌️
Latest comments (18)
I strive to use a risk assessment to decide what to test. I'll assume the following definition:
risk = chance * effectFor 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:
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'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 :)
I set up automated testing for rest APIs using restAssured
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.
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!
I always forget to build with testing in mind from the start, and then I suffer the consequences.
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.
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?
Thank you, Chris! Sarah's article was very useful, thanks for sharing it!! 👍
You are absolutely right, I will keep the 5 factors in my mind when I apply testing in my next side project.
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.
Thank you, Idan! I think this is something that kept me back from writing tests in the past. Unit tests seemed to me always to be an overkill for the few functions I had. My apps are often connected to databases and Web APIs, so I think integration tests will be also my preferred type in the future 👍
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...!
Thanks @alephnaught2tog for your reply! I'm also still a student, so in university, we learned formal testing in theory, but in our study projects, we never really applied it, because time was always very limited and the whole application was just a proof-of-concept, so nobody cared 😇
In my side projects I tested my apps just by trying them out and see if they crashed. When they crashed, I tried to fix them immediately, but if this took too much time I often let my future self a
// TODO:note to come back later. But I think after I've seen formal testing can be so easy, it will reduce my time to manually testing things.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.
Most testing tools are bloated, in my opinion - it shouldn't take very long to pick up a testing tool, if the tool leverages your existing knowledge of the language, but most test frameworks replace everything with assertion functions.
Try something like tape.js for testing - it's very small, and has only a few assertions that are necessary to do things like deep comparison. It seems to follow the Go language testing philosophy of "less is more" and leveraging what you already know.
I love that! Writing tests is so much more intuitive, and your tests will be much easier for someone else to read.
Same. When I'm building something small to learn a new technology I forego it.
If it's a bigger side project I plan to develop for a while I'll add static typing and selective tests for modules that seem fragile.
Not a religious tester by any means. Haven't actually been at a company yet that required tests so maybe I have not seen the light.
Thank you, Natti! Good to see that most devs go for tests, but don't do over-testing!
Thanks Ben, I see your point! 🙂