After two years of development and incubation, we are very excited about the launch of Rescale’s ScaleX Enterprise platform in May.  This solution was built with the goal to provide IT leaders and managers with the tools to fully leverage the efficiency and financial advantages of a cloud simulation platform and HPC infrastructure. We’ve combined our award-winning cloud simulation platform with key enterprise capabilities yielding the ideal HPC environment for organizations looking to transform and integrate their on-premise infrastructure with the cloud.

A few of the key features of ScaleX Enterprise are:

  • Consolidated Platform–  ScaleX Enterprise provides a unified environment with an intuitive interface that allows companies to access both on-premise and cloud simulation resources in one place. The platform can also be natively integrated with existing schedulers, creating a more efficient and scalable workflow for users.
  • Admin Panel– IT leaders are given complete administrative control through the ScaleX Enterprise admin panel where they can create and administer accounts by users, groups, and role-based permissions.  Security is heightened through centralized access control and usage and resource monitoring also allows for improved budgeting and more accurate project planning.
  • Remote Visualization– Our new Desktops feature gives you the ability to perform remote visualization in the cloud through a standard Internet connection, allowing you to visualize your 2D/3D results with interactive performance.
  • Instant access to unlimited hardware and software– Our collaboration with software partners and infrastructure providers around the world allows us to provide a scalable, pay-as-you-go cloud environment that yields better results in less time

ScaleX Enterprise enables CIO and IT leaders to transform and expand their existing HPC environment, giving engineers and scientists access to the unlimited resources available through Rescale’s simulation platform, while still maintaining administrative control.  This agile and seamless solution ensures that your organization stays on the leading edge of innovation with increased efficiency, enhanced product development, and accelerated time to market.

For more information on how ScaleX Enterprise can transform your IT organization please don’t hesitate to contact our team for a consultation at

This article was written by Sarah Dietz.

At Rescale, we were using the Jest framework by Facebook to test our React and Flux application. Jest is a simple-to-get-started testing framework with an API similar to that of Jasmine, but with automatic mocking of CommonJS modules baked in. However, like many developers in the open source community have noted, we’ve found that Jest can be unbearably slow when running a non-trivial test suite. For our test suite of about 60 test cases, it takes well over 10 seconds to finish! This article explains how we’ve ditched Jest in favor of Karma, Webpack, and Jasmine. The same test suite running under our new setup takes only a little under 200ms to execute in PhantomJS, after the initial Webpack bundling.

Our testing setup is based on the one explained in this article: Testing ReactJS Components with Karma and Webpack. Read that if you are unfamiliar with Karma and Webpack. To summarize, this setup uses karma-webpack to bundle all of our tests into a single file which Karma loads and runs in the browser. The npm packages needed for this are:

  • karma
  • karma-cli
  • karma-jasmine
  • karma-phantomjs-launcher
  • karma-webpack
  • jasmine
  • webpack
  • core-js (for ES5 shims)
  • babel-loader (for ES6 to ES5 transpilation)

The Karma configuration file, karma.conf.js, should look something like this:

And the entry point for the test suite Webpack bundle, tests.webpack.js, should look something like this:

Here’s a sample test, located at ./src/js/components/__tests__/MemberList-test.js which tests the component ./src/js/components/MemberList.jsx:

That’s all well and good for testing React components, but testing Flux applications, specifically Flux Stores, requires a little more setup.

Testing Flux Stores

The problem with Flux stores is that stores are usually singletons with state, and singletons with state can quite possibly be one of the worst things to test because their state persists between tests. It becomes hard to predict the state of the store when many parts of our application interact with it throughout the test suite. You might be thinking that we could just implement some method to reset the state of the store before each test case, but doing this for every store is a maintainability nightmare and is very prone to errors.

Jest solves this problem by running every test case in its own environment. In other words, when we require a module in a test case, the module imported is a fresh instance. This is exactly the behavior we want when testing stores.

With Webpack, we can do just that: clear the require cache before each test case, so that calls to require loads a fresh instance of a module. As an optimization, we wouldn’t want to remove third party modules, such as React, from the require cache. Doing so would slow down our test suite significantly, and none of those third party modules should be singletons with state anyway. We can add cache busting before each test in the tests.webpack.js file like so:

That’s all there is to busting the require cache. Now modules are cached within each test case, but aren’t in between. Stores, actions, and dispatchers are all isolated between tests.

Testing the Actions/Stores Boundary

We use Reflux as the Flux implementation for one of our projects, and Actions are pretty much the public API for Stores. Triggering an action is an async operation though, so we need a way to control asynchrony in our tests. This should be easy with any testing framework or library that provides facilities to mock out the native setTimeout and setInterval functions and manually advance them. Here is an example of testing the Action/Store boundary with Jasmine:

Mocking a Module’s Dependencies

Say we want to test a module that has a dependency on another module that we want to mock. One example could be that we want to test an api module that depends on some http module like axios. This is where Jest shines because they make it easy to specify mocks with its jest.setMock(moduleName, moduleExports) API or with their automatic mocking facilities.

One way to achieve this outside of Jest is to use rewire and its webpack version rewire-webpack. Rewire can be used to change private variables in a module. For example if we want to mock out the axios module within our api.js module, we can write something like this:

Another option is to, once again, manipulate Webpack’s require cache:

The benefit of this over rewire is that every call to require(‘axios’) is mocked, not just in the module that we rewired.

Note: Mocking an http request library is probably a bad example. For that you should use something like jasmine-ajax instead, but you get the idea.


We saw around a 50x speed improvement in the execution of our React and Flux application test suite using Karma and Webpack over Jest. However, it does take a bit more knowledge and effort to set up compared to Jest, and mocking a module’s dependencies isn’t as easy. Jest is really nice since it’s easy to set up, but that it’s so slow is a deal breaker for us, and we don’t know if it’ll ever be fixed. In the mean time, our current setup allows us to effectively TDD.

This article was written by Kenneth Chung.