loading...

Do you apply testing in your side projects?

across_the_grid profile image Nicho Updated on ใƒป1 min read

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 โœŒ๏ธ

Posted on by:

Discussion

markdown guide
 

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.

 

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!

 

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.

 

Thanks Ben, I see your point! ๐Ÿ™‚

 

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.

 

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?

 

Thank you, Chris! Sarah's article was very useful, thanks for sharing it!! ๐Ÿ‘

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

You are absolutely right, I will keep the 5 factors in my mind when I apply testing in my next side project.

 

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.

 

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 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.