Welcome to the Treehouse Community

Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.

Looking to learn something new?

Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.

Start your free trial

JavaScript JavaScript Unit Testing Behavior Driven Development with Mocha & Chai Writing Our First Test Suite

Alejandro Molina
Alejandro Molina
3,997 Points

For those who do Unit Testing...

What is your experience with it on the job? Are you doing it this way and do you find it makes you do your job a lot better? Doing a lot of guess work on what the functions should do on your test then actually writing the functions?

It does seem like a lot of upfront leg work for sure.

4 Answers

Kirsty Pollock
Kirsty Pollock
14,261 Points

I have always tried to write unit tests for pretty much everything, for most of a 20+ year career (I stumbled into the usefulness of thorough testing, entirely on my own, in my SECOND project at uni way back in 1988... the first had been messy and stressy, testing every single function as I wrote it made the 2nd one indescribably better...).

I once wrote a paper for a company I worked for on benefits and expected effort for proper testing (including integration testing, ui testing, testing the installs etc etc and the use of tools in automating testing). Using my experience and the info I found from research, I think I recall saying that the time to write (and test) unit tests takes 1-4 times the amount of time to write the code (but that overall development time TO CORRECTLY WORKING PRODUCT was reduced.

That's right - at least as long as the code itself and possibly FOUR times as long and by gawd is it worth it in sanity and calm (esp with good DevOps/continuous integration support). A release can become a real "nothing" event...

When you have testers in the team (highly recommended!!), IMO, you need a minimum of 1 per 2 devs, ideally 1:1 for any project with ui, just to keep the tests running at a pace that keeps up with development. Ideally they are experts who also write tests.

I am NOT a TDD as seems to be defined these days. I am iterative, but write far more bottom up, and I would always e.g. get a working database in preference to mocking (just my experience, mocking data is no quicker and very frequently fails to identify SERIOUS issues), but I DO write tests for almost every damn thing, (including database procedures etc) and make sure they keep current and passing. (Unless flat out not allowed to by management - but that isn't then a place I'd ideally work...).

Oh, and never attempt any significant refactoring without a good suite of tests (all types!). Or you are just flying totally without safeties (IMO):

I have worked in companies huge and tiny and I would say the same for both in principle - seems harsh, or overkill, but software should really work right without killing people with overtime and panic. I have seen it work well (and of course seen the opposite - that is why I have an opinion!!).

This is all just my opinion borne of my own experience. YMMV.

Hope this helps!

It's great to see the views of someone with almost three decades of experience in software development. I didn't even see / know about computer back in 1988. I never thought people would had taken testing seriously back then. It's awesome to hear your opinion and even more awesome to see you still coding & learning, Kirsty.

Well, it depends on the project timelines and the quality levels project is expected meet. Typically, at the start of the project, managers / architects push for "Test-first approach" or "Test-driven development" and slowly this initial enthusiasm gets carried away (my personal experience); although there are some projects that practice this religiously. That said, unit tests do help in the long run once they are integrated into test automation. You will certainly feel more confident if you get to know that the test suite (comprising of few hundreds or thousands of test cases) are running without issues when you do a change to the project (kind of proves that you didn't break the existing code).

Developing Unit Test cases takes time and imagination. Certainly there is a price to be paid for it beforehand, but it does reap benefits in the long run.

Dan Bearden
Dan Bearden
24,231 Points

We have sites that contain 1,000+ javascript files along with weekly deployments to our production environment, modularized shared components across our projects, and many teams making changes to all of it at any given moment. Having a high threshold of testing coverage allows us to greatly reduce our regression testing efforts in this kind of environment. We also have Git hooks that will fail to push Git commits or break Jenkins builds if that threshold is not met from unit testing to help ensure that we do not let our quality degrade over time. We have used many different frameworks, mainly Mocha/Chai on our projects, and lately we have started using Jest which is awesome for testing our React apps. We definitely take our testing seriously and it pays off in the long run.

Kirsty Pollock
Kirsty Pollock
14,261 Points

Thanks. It is a profession in which one is always learning ... :-)