The Benefits of Test Driven Learning With React JS
The Benefits of Test Driven Learning With React JS
Dave Bush provides an example of the benefits of using test-driven development while learning a new framework.
Join the DZone community and get the full member experience.Join For Free
Download the blueprint that can take a company of any maturity level all the way up to enterprise-scale continuous delivery using a combination of Automic Release Automation, Automic’s 20+ years of business automation experience, and the proven tools and practices the company is already leveraging.
As I mentioned last week, I’ve been learning React JS over the last month or so. Up until the start of this project, I would learn a new framework, and then I would try to paste in Test Driven Development after the fact. I would use the excuse that because I didn’t know the framework well enough, I wouldn’t be able to properly write tests for it.
But this time, I decided to do something different. What if I wrote tests for my demo application as I was learning this new framework? My reasoning was that learning how to test code written in the framework was just as important as learning the framework.
What follows are the lessons I learned from this wildly successful experiment.
I Learned the Framework Better
As I’ve written before, most people don’t test because they’ve never learned how. When you are learning a new framework, in a lot of ways you start out at that same place all over again. Yes, you’ve got all of your previous testing experience to fall back on, but in a lot of ways, because you don’t know the framework, you don’t really know how to properly test the code you are writing. So, doing anything takes a lot more time than it would if you just wrote the code and ignored testing.
But what I learned by forcing myself to write test as I wrote the demo – either before, as TDD should be practiced, or immediately after – is that this all helped me learn the framework better than if I hadn’t.
- I stopped thinking of JSX as HTML and instead saw it as code with objects that can be mocked.
- I saw that the Flux system worked best as a “notify with data” system rather than a “notify and pull” system.
- I was forced to fully understand Flux.
- I was more inclined to enforce the Single Responsibility Principle both at the View level and with Flux.
I Learned How to Test the Framework
This probably seems obvious. But this gets back to the problem with my normal way of learning a framework. Let’s take something like Angular as an example. I know Angular 1. I can get a pretty respectable application put together in it. But, because I didn’t learn it using TDD, I would be the first to admit that my ability to unit test an Angular application is pretty weak. I’m actually planning to go back and rework my Angular 1 and Angular 2 reference applications using TDD just to get that experience.
I recently started working with EXT again. This time with version 6. Guess what I spent the first couple of days learning how to do? That’s right. “What’s the best way to write code using EXT 6 that makes the code testable?” How did I answer that question? I wrote tests.
- If you use the ViewModel and ViewController and never have either call the View directly, you can create highly testable code.
- Unit tests in EXT are best written using PhantomJS instead of JSDom. Although, I’d still like to go back and try to make JSDom work.
In React JS, I learned:
- View components are easier to test if they only do one thing. Favor composition over monolithic view component.
- Stores (the part responsible for CRUD actions) can also be EventEmitters.
I Didn’t Develop Bad Habits
This one, to me, is probably the most significant reason for me to repeat this process in the future.
Here’s the deal. Every other time I’ve learned a new framework or language, I’ve learned it from a “let’s just get something working” perspective. If I concentrated on testing at all, it was after I got it all working.
The problem with this method is now I’ve learned how to get something working, but I haven’t really learned the best way to organize my code so that it can be tested or swapped out later if I need to.
By writing my code using TDD, I will have to write the code in a way that is testable the first time. This means that while it may have taken you over twice as long to get that first demo application up and running, all future applications will be written in a more efficient, more testable, and easier to maintain.
I Learned How Testable the Framework Really Is
If you read last week’’s article, you know that the testability story for React JS is what really got me excited. None of the other frameworks I have used have been testable starting at the view level. This is one of the areas where Angular could improve. I wish I had leaned Angular 1 using TDD because then I would have either figured out how to test decorators on directives or I would have found out that it is only possible under the certain conditions.
So far, I think React is incredibly testable. Although I have not had a chance to do some of the things I’ve done with Angular yet.
I Learned Where the Holes Are
So, I invite you to try it yourself. The next time you are learning a framework, learn ALL of it by testing it along the way.
Published at DZone with permission of Dave Bush , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.