You Should Have a Test Suite

Software tests improve confidence in an application’s behavior, make it easier to grow and maintain, help identify breaking bugs and can even serve as a form of documentation. For a developer practicing TDD, writing tests is even an essential step before writing any application code.

The problems tests mitigate are expensive to resolve, so really they help organizations as much as developers.

Of course, tests don’t write themselves, and there is a cost associated with creating a comprehensive test suite for an application. One of the hurdles to creating a useful test suite is building the infrastructure required to write and run tests. Applications are complicated beasts, and useful tests need to handle that complexity.

Inspiration

Recently, I created a test suite for a client’s Node.js project. I love working in Node.js because it’s an un-opinionated framework that grants a lot of freedom to developers to tap into the huge ecosystem of JavaScript packages. That huge ecosystem extends to testing tools as well, so even for someone that has done a lot of JavaScript testing, setting up a test suite for the first time, or adding new tools to an existing test suite, can be a significant undertaking. I wanted to share the testing tools I use on Node projects, and demonstrate how to configure them to build a test suite that is scalable and provides meaningful feedback about an application. Testing in Node is a Skill Pack on The Frontier I created to do that.

Note that even though the series focuses on adding test coverage to a Node app, most of the tools and strategies can be used for any JavaScript app.

The Series

Over the course of the series, we’ll be adding test coverage to a full-stack messaging app called ChattrBox. You may be familiar with this app from the Big Nerd Ranch Front-End Web Development Book or our Full-Stack and React Essentials Bootcamp. It’s a modern, full-stack web app that has a Node backend running web sockets and a REST API to power the frontend’s chat interface. If you’re learning web development, I encourage you to follow along with the book and build the app yourself. However, if you just want to learn how to use some JavaScript testing tools, you’ll be able to download the application code from the Frontier and focus on the screencast material.

The series doesn’t cover testing philosophy or offer any opinions on what is or is not a good test, but it will show you how to add and configure a set of tools that will enable writing thorough tests to support an application. If you’re looking for thoughts on how to write good tests once you’ve got the tools set up, take a look at some of the testing blog posts by other Nerds.

Summary

If you’re new to testing in JavaScript and Node, this is a great series for you. If you have an existing app and test suite that you want to expand, you should be able to cherry pick some screencasts from the series that provide valuable direction for your unique situation.

The series describes my approach to Node or JavaScript testing, and there are plenty of other valid approaches. If you prefer another tool or strategy, tell us about it in the comments. Also, feel free to ask questions in the comments section. We’ll get someone to help you out.

The series starts with the ‘Basics’ video, so I’ll see you over there when you’re ready to get started.

The post Testing in Node — a New Skill-Pack on The Frontier appeared first on Big Nerd Ranch.

When React Native Makes Sense

There are three versions of the React Native story. One says that React Native is a silver bullet that allows you to ship two apps for the price of one. Another would have you believe that React Native is the same, disappointing cross-platform novelty we’ve seen before with familiar shortcomings. The third story is the truth, and it’s somewhere in the middle. When React Native’s strengths are aligned with a project, it’s a very attractive option. The following are some questions that you can consider to determine if React Native is a good fit for your organization or project.

Are You Building an App for iOS and Android?

The biggest selling point for React Native is that you can use one codebase to ship apps on multiple platforms, so it makes sense that React Native is helpful for any organization building iOS and Android apps simultaneously. 100% code reuse between platforms isn’t common, but it is quite feasible to reuse the majority of code in an app. When reuse isn’t an option, it’s a straightforward process to write platform-specific code. So while you don’t get two apps for the price of one, you do ship features faster across platforms compared to developing two separate apps. This has positive cost implications, and it can be even more valuable for MVP apps built to answer market questions as quickly as possible.

That’s not to say that React Native is only a good choice when building two apps at the same time, though. Focusing on developing either an iOS or Android app before building its counterpart can reduce development time on the second app thanks to reusing React Native code.

What Are the Design Goals of Your App?

React Native creates truly native experiences because it allows JavaScript code to interact with native components via a mechanism known as the bridge. This is a key distinction from hybrid-app solutions built on Cordova like PhoneGap or Ionic that create the same webviews on any device that runs the app. In React Native, a button in an iOS app is the same button component that a native iOS app will use. As powerful as the bridge is, it introduces some performance limitations on React Native apps that rely heavily on animation or other computations. (That doesn’t mean React Native is a lost cause in these situations, though.) If the vision for your app doesn’t rely on extensive animations or unusually high CPU demands, building a fast, engaging native experience with React Native is an attainable goal.

Despite those concerns, there are good reasons to be optimistic about the direction React Native is going. One of the great things about working with a thriving and popular open source technology like React Native is that the limitations facing it are constantly shrinking. Facebook is working on architecture changes that will improve bridge performance, and third-party contributors are solving problems by building solutions that benefit the whole community.

Another design consideration for cross-platform apps is, how closely does the app need to adhere to platform expectations? It is certainly possible to use React Native to create a floating action button for Android users to enjoy, for example, but that requires an Android-specific solution that can’t be reused for iOS. Creating a similar feature for iOS users would require separate iOS code and design. User experience is important no matter what kind of app you’re building, so we generally recommend using platform-specific conventions. Still, it is important to keep in mind that each feature unique to a platform will also require unique code, and using React Native makes the most sense when the least amount of unique code is required.

What Is the Composition of Your Current Dev Team?

If you have dedicated iOS, Android and web teams supporting existing apps, then React Native might not close many gaps for you. For everyone else, though, React Native probably fits into your organization. Training an iOS or Android team to build React Native apps allows them to leverage their existing platform knowledge, and they’ll have an easier time picking up the platform they’re less familiar with compared to a developer without a mobile development background. For web teams, many are already comfortable building React apps and are positioned to easily make the jump to React Native development. Even web teams that don’t use React will probably learn React Native faster than they could learn Android or iOS platform tools. And if you don’t have a dev team at all, it will be easier to find JavaScript developers than anything else.

An important caveat to keep in mind is that while the majority of a codebase can be written in JavaScript and shared between Android and iOS apps, there will probably be edge-case issues that require native code and tools to solve. Fortunately, React Native makes it easy to drop into native environments. When it becomes necessary to do so, though, a native developer’s experience is invaluable.

Regardless of the team adopting React Native, developers generally find significant benefits in the framework due to tooling conveniences like hot reloading and a powerful debugger, a wealth of open-source libraries that solve problems for them and an active community striving together to build exceptional mobile apps. These elements contribute to making more effective developers who produce code quicker.

React Native has strengths and weaknesses like any other technology; using it in the appropriate situation will let its strengths shine while minimizing the impact of its weaknesses. If React Native is appealing to you because you believe it will cut your development budget in half, or that your React developers building web apps are already prepared to create flawless iOS apps, your expectations might be setting you up for disappointment. However, if you plan to build an app for Android and iOS with a new or existing team that is excited to explore new technologies, React Native could reduce development time as well as some costs.

If you have an app you’re excited about building, get in touch with us to see if React Native could be the right tool for the job.

If you’d like to know more about what adopting React Native could mean for your organization, take a look at some of these firsthand accounts from companies that decided to use React Native, for better or worse.

• Walmart
• Zynga
• Airbnb

The post When React Native Makes Sense appeared first on Big Nerd Ranch.

As consultants, it is part of our job to recommend technologies to our clients for use in their projects. React Native is one such technology we consider to reduce development time and save clients money. React Native is great for certain use cases, so it’s a technology our web team has been learning. This blog post is not about React Native, however.

If you pay attention to JavaScript frameworks, you’ve probably heard of the new hotness, VueJS. It’s popular for its Angular-esque directives and React-ish components, as well as its speed and ease of use. A technology based on VueJS that could perform the same write-once-run-anywhere magic (As long as ‘anywhere’ is iOS or Android) as React Native would be exciting, indeed. Enter Weex.

Weex is a JavaScript library that tries to fill a React Native-sized gap in the VueJS ecosystem. I wanted to see if Weex might be a viable technology we could bring to clients. After a few days of experimentation, I realized Weex and its documentation were not yet developed enough to for us to use to deliver top-quality apps. This was my experience with Weex.

First, a few caveats. Significantly, I don’t speak or read the primary language of Weex developers. Weex was developed by a Chinese team, and most of the technical conversations surrounding Weex are held in Chinese. There is an English version of the documentation, and Google Translate helped cover for my monolingualism, but if you read Chinese, your experience could be very different from mine. Second, I don’t have any Xcode or Android Studio experience, which would have been very useful.

In other words, Weex has a high barrier to entry for web dev teams without Chinese literacy.

When I first tackled React Native (after the release of create-react-native-app), I was impressed by how easy it was to start developing. I entered my foray into Weex with expectations set by React Native’s high bar. It didn’t take long for me to temper those expectations. After creating my first project with the weex-toolkit command line tool, I found a breaking bug in the boilerplate project. It was a simple typo in Webpack’s config file, and it has since been fixed, but it was a good indication of the WIP nature of Weex.

Out of the box, Weex provides a browser-based app preview. Skipping mobile simulation keeps Weex lightweight and familiar, but VueJS code can render correctly in the browser when it doesn’t work on native devices. This means iOS and Android simulators are still necessary to fully test Weex apps. Still, the browser preview provides a nice, quick way to confirm that your code mostly works.

My next step was setting up the iOS simulator in Xcode. I followed the documentation to the best of my abilities, but was unable to get it working. I recruited one of our rock star iOS devs to help me uncross some wires and was rewarded with a simulator running a Weex project … that was different from the Weex project running in the web preview. I spent the next few hours figuring out how to connect my JavaScript project with the Xcode one.

After a full day of tinkering, I had a functional dev environment setup. It was a fun learning experience, but one of the things I learned was that the Weex docs were not yet developed enough to support our needs.

I started day 2 with the goal of building a basic goal tracking app. The Weex component library was barebones, and there were not many packages to flesh out the core offerings. The libraries that did exist were time consuming to setup and suffered from the same documentation limitations as Weex. At the end of the day, my ‘app’ was a single screen with an input box and a button.

Reflecting on two days of work, I decided the process had required too much effort without yielding enough results. True, I had worked through Weex’s biggest challenges in setting it up, and my development time would only increase as I became more familiar with it, but as of now it’s not a good fit for our work. We need to ensure our projects are easy for client developer teams to take over, and as Weex continues to grow and evolve, it’s hard to predict how that experience will change for new developers. When Weex has friendlier documentation and a gentler setup for new devs, we’ll revisit it as an option for future projects.

At Big Nerd Ranch we like to keep an eye on emerging technologies because, well, we’re a bunch of nerds, but also because we need to know what the best options for our clients are. If you’ve got a problem you want to solve, get in touch. We’d love to talk about your options.

The post Is VueJS’ Weex a Suitable Alternative to React Native? appeared first on Big Nerd Ranch.