Testing React Components Using Shallow Rendering

Previously we tested React components with Jasmine and jQuery, but what if we want to test without having a DOM available? React's testing tools have you covered with Shallow Rendering. Shallow Rendering will render the object as it would before sending it to be painted on the screen. This makes the final state of a component available for testing.

Testing React Components With Jasmine

Making a React component feels straight forward. Testing a React component should feel just as straight forward. Now that I have built tests for my React code, I can say it is.

Tweak the Angular Test By Controlling the Template

We recently finished bringing our test coverage up to 90%+ on our Angular project. The team worked hard and I am proud of our accomplishments. Going forward we are using TDD and this has proven to be an interesting experience that has provided new challenges. We have found building Angular directives through test driven development to be a little challenging since the templates haven't been built yet. We aren't going to know what to build right away, and we are loathe to break our rhythm and constantly be updating a template file. A bigger problem is the template creating an external dependency which is never a good thing for unit tests. When it comes time to do e2e testing and using Selenium or Protractor then the whole template needs to be run. If I'm starting with unit tests to define my code, how can I use a template without these problems? We found one method that we like - the $templateCache.

You Got Karma in My Require, You Got Require in My Karma, No Worries We Have Define

Karma is a pretty powerful test runner for JavaScript. Most of our code is in Angular, so we load our Karma test context with every file in our project. This should be easy...except...we do have a few libraries that only load on demand. This is no problem for the Karma context since the file is loaded along with everything else. The problem is that we use require to load it.

ngTestHarness: Strap in with this new testing helper for Angular.js

This is the first time I can point to open source code that I took a large part in authoring. I am proud of the project that the very talented Team Titan at Gaikai, a Sony Entertainment Company, has created. While updating/adding unit tests for development and build purposes we became very disenchanted with the complexity required for creating unit tests in Angular.

Angular and Jasmine: Injecting into the test environment

UPDATE: The team at Gaikai, where I work, has released an open source testing framework for Angular which streamlines this process and greatly simplifies the testing process. I wrote about it here: http://randomjavascript.blogspot.com/2015/01/ngtestharness-strap-in-with-this-new.html

I have set my sights on improving my Angular proficiency, however I am not ready to give up on all my other tools. I have a strong preference for Jasmine, and the recent release of 2.0 further cemented that comfort zone. Jasmine 2.0 made major improvements by removing window dependency and improving async support. Using Jasmine and Jasmine-Node together allows me to write tests in the same language for both server and client. I prefer to standardize as much as possible on a project, and having one language for tests on both application tiers is valuable to me in time and effort saved.

Jasmine-Node and Rewire, Part 2: Making the test complete

In the previous post I introduced the concept of using Rewire with Jasmine-Node to simplify Node.js unit testing. Rewire added a __set__ and a __get__ function to the module which let us grab a function in the module, and test it directly. We could test the function's output by controlling the objects that the function worked with, and checking them upon function completion. We didn't need to manipulate any internals of the function so our testing is still honoring the "Black Box" concept of unit testing. The idea is that the unit test only cares about what the testee can take in, return, and manipulate outside itself. How that operation is performed is not important to the unit test.

There was one test we didn't look at which I want to discuss now.

Jasmine-Node and Rewire, Part 1

Node.js development can be a lot of fun. Unit testing can be fun too. Unit testing Node can be very much not fun. Unit testing Nodejs modules often feels like trying to build a neutered integration test with mocks, nocks, and intercepts. Since Node is a web server whose functionality revolves around responding to http requests, the most natural testing method would be to trip those URLs and check the response. However, that ends up being more of a test of the middleware, and doesn't allow for testing the function directly. If you want to ignore the http calls, the most rational way to test the functions inside the module would be to export them. Once exported the tests can easily be run against the exported functions. The problem with exposing all the functions via export means functionality that should be private is no longer private.

Using Nock and Jasmine-Node to Target Your Server's HTTP Requests

I am continuing along my path of "test driven development" discovery and am finding it fraught with challenges. All my progress has shown me how crucial TDD is for success, and I am constantly reminded of how effective it is. The latest challenge I had was to test the outgoing http call of my node server. I was testing a module that sent an http request in a private method. It was crucial that my testing confirm the outgoing URL. This is not as straight forward as it sounds.

Using --Configure in Jasmine-Node Command Line

I recently had the honor of one of my minor changes to the Jasmine-Node project being merged into the project master branch. I added a new option to the command line used to invoke the Jasmine-Node tests. Using a --configure option followed by two additional entries will add a variable to the process.env in the invoked node process. Adding this feature allowed me to move my tests with my node server through it's path from testing to production.

Using Jasmine-Node to Test Your Node Server

I've been working with Jasmine to test my client side code, however, my code extends beyond the client. I am working on server side JavaScript using Node.js. It would be great to apply my test driven process to my node server as well. Luckily, the Node community is large, helpful, and talented. Jasmine has been ported to the server with the jasmine-node project by Miško Hevery (https://github.com/mhevery/jasmine-node). The github readme summarizes the process of setting up jasmine-node, so this post will expound on those points.

Building a Unit Test in Jasmine, Part 4

The last part in this series is going to involve some time travel.  Physics aside, let's assume six months have passed since our original JasmineTester object was created.  The object was a great success and has been embedded all throughout the organization.  We have forgotten the details of our earlier work as multiple other projects have come and gone.  While still basking in the glow of our earlier success, a new requirement comes down the line: make a new object exactly like the JasmineTester but with multiplication.  Thanks goodness we used Jasmine!

Building a Unit Test in Jasmine, Part 3

We created a Jasmine unit test example in the first two parts of this series that started with a statement and then abstracted out to an object.  This time we will expand the object to be more robust.  Most importantly, we are not changing the tests currently in place.  

The JasmineTester is going to be updated to accept a random number of values.  The first step is to create a unit test to describe this.  The number of properties being added is upped to 4.  The new test will check to make sure the new object constructor still returns an object by using the toBeDefined matcher.

Building a Unit Test in Jasmine, Part 2

In the previous part, I showed an extremely simple test whose only purpose is to highlight how Jasmine works. This post will take those pieces and start doing something more dynamic with our source code. The Source and the Spec are going to change.

One reason to unit test is to confirm your code works despite internal changes to the source. As your application changes and matures, it can be daunting to ensure your old code still works. Properly created and maintained unit tests make this much less scary. You add a feature, run all your tests. Everything passes, then you are in good shape. If something breaks, you know it now and not when the customer finds it. Once everything passes you can move on to your next set of changes with relative certainty your application still works.  This post will set us up to show that principle in action over the next 2 posts.

Building a Unit Test in Jasmine, Part 1

(Thanks to Dustin Butler for the inspiration that led me down this path.  His great and more in-depth article is at Unit Test JavaScript Applications with Jasmine)

Unit testing and I have had a tumultuous affair until now.  Every few months I would pick up a book, go on a blog reading binge, or try out a framework.  It would never work out.  I would get frustrated or work would intervene and off I went.  Unit testing and I were almost fated to always be apart... <cue the romantic music>
An opportunity came at work to create a new feature on our web platform.  I decided to take a chance and build it from unit tests.  It was a great opportunity to start clean with very few dependencies to worry about.  The lack of entanglements made it easier for me to understand how unit testing would work to describe this new piece.