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.

Making Your First React Component Raise Events and Update (update to v0.14.x)

My last article described creating a simple React component. This post will walk through adding a click event to that component. The click event will modify the data the component is displaying. React will automatically update the screen without us making any explicit requests based on the change in data.

Making Your First React Component (updated to v0.14.x)

Update: Fixed example with 0.14.x ReactDom format and to use states, not props.

In a world of Angulars and Embers, what is the point of a library that only provides a third of the MVC equation? React offers simplicity and a welcome decoupling of display and business logic.

Look! No Hands! - Using Selenium and Node.js for interactive UI testing

Selenium is the most talked about UI testing framework that I could find that was both open source and well supported. We decided to adopt it for our automated UI testing. I have found it to be very useful, albeit with a stiff learning curve. One downside for me is the back and forth between building tests and then waiting for Selenium and the browsers to open and run the tests. It occurred to me I could help alleviate this by having the browsers at the ready and eagerly waiting for the command to start testing. So I reached into my toolbox to grab one of my favorite tools, Node.js. Using Node.js I was able to build an interactive interface with which I can iteratively build my front end tests. Everything I needed was already there, I just had to put pieces together.

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.

An Angular-ized Require-Based Script Loader

The co-author for this approach, who did a lot of the heavy lifting, is the very talented Nate Ferrero.

We recently found another speed bump as we carefully drove down our path to removing require.js in favor of Angular purity. We found hidden dependencies nestled into the code. Code development of any substantial kind that lives for any substantial amount of time with multiple developers quickly gains warts.

Building an Angular List: Using ng-repeat

There are many things about Angular that make it an excellent framework to use, and one of my favorites is the way it's data binding simplifies the implementation of UI elements. One of the most useful elements, in my opinion, is the ng-repeat. Ng-repeat makes creating lists so simple that you will want to use them all the time.

The jQuery Radio: Custom Triggers For a Pub/Sub Model

I like jQuery. It's the first library I used that gave me the "JavaScript is Awesome" tingle. Putting aside the many arguments for and against, jQuery is still used all around the web. When building from scratch we may choose more modern frameworks. However, building from scratch is a fine luxury and the exception to the norm. Many JavaScript programmers, if not most, spend their time improving existing sites and adding additional functionality. The result is that many of us still use jQuery on a daily basis. jQuery is also a great library for JavaScript beginners to get started with. So this post will visit one of jQuery's neatest features, "trigger".

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 CSS Media Queries as a Data Transport

Sorry for the long delay. I recently changed jobs and with family I had no time to get this out. I am going to try to return to every other week articles again.

My recent work involved creating web destinations based on both dynamic content, dynamic form, and responsive design with no preset dimensions. The pages would have to adjust to fit multiple sizes set at compile time. Each size could have its own specific properties and shared properties. The one thing I did know was that I could rely on any screen specific properties to have an identifier appended to the property name to make it unique. I needed a way to find the correct identifier for the current screen size. To make this work we decided to use CSS to store it. The solution worked for all modern browsers. Internet Explorer 8 received an alternate css and workflow since it doesn't support the MediaQueryList object.

Tips For Using JsDoc on Enyo Kinds, and Other Factory Pattern Types

My journey to better practices has led me through the forest of unit testing to a new destination. I have reached that dark, scary marsh that many in the IT world dread. The very mention of its name sends grown men to tears and panic. I find myself at the Marsh of Documentaion!

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.

Solve the Problem, Not the Behavior

In my past life of consultancy I became very used to working on other people's code.  One of the most important lessons I learned was to "find the problem first".  Errors are a behavior you witness.  Debugging is fixing those errors.  Most developers would consider those reasonable statements.  There is an underhanded trick here though.  Some developers might make the mistake of a direct connection between the two, but there isn't.  The error you witness may not be the error you need to fix.

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.

Bubbling in Enyo2, Part 3

Our first example was a simple event bubble from a button to a parent object.  The second example re-used the button object within two separate parents that handled the bubbled event differently.  Let's go one step farther.  This time the button's event will bubble all the way up the parent hierarchy.