Does Jest support ES6 import/export

babel-jestecmascript-6jestjs

If I use import/export from ES6 then all my Jest tests fail with error:

Unexpected reserved word

I convert my object under test to use old school IIFE syntax and suddenly my tests pass. Or, take an even simpler test case:

   var Validation = require('../src/components/validation/validation'); // PASS
   //import * as Validation from '../src/components/validation/validation' // FAIL

Same error. Obviously there's a problem with import/export here. It's not practical for me to rewrite my code using ES5 syntax just to make my test framework happy.

I have babel-jest. I tried various suggestions from GitHub issues. It is no go so far.

File package.json

 "scripts": {
    "start": "webpack-dev-server",
    "test": "jest"
  },
      "jest": {
        "testPathDirs": [
          "__tests__"
        ],
        "testPathIgnorePatterns": [
          "/node_modules/"
        ],
        "testFileExtensions": ["es6", "js"],
        "moduleFileExtensions": ["js", "json", "es6"]
      },

File babelrc

{
  "presets": ["es2015", "react"],
  "plugins": ["transform-decorators-legacy"]
}

Is there a fix for this?

Best Answer

From my answer to another question, this can be simpler:

The only requirement is to configure your test environment to Babel, and add the ECMAScript 6 transform plugin:

Step 1:

Add your test environment to .babelrc in the root of your project:

{
  "env": {
    "test": {
      "plugins": ["@babel/plugin-transform-modules-commonjs"]
    }
  }
}

Step 2:

Install the ECMAScript 6 transform plugin:

npm install --save-dev @babel/plugin-transform-modules-commonjs

And that's it. Jest will enable compilation from ECMAScript modules to CommonJS automatically, without having to inform additional options to your jest property inside package.json.

Related Solutions

R – How to determine if an Entity with relationship properties has changes

There is a way to get the state of a relationship, but it is not as easy to obtain as the state of an entity.

ObjectContext.ObjectStateManager.GetObjectStateEntries(System.Data.EntityState state) returns IEnumerable<ObjectStateEntry> with entries for both, entities and relationships (there is IsRelationship property on ObjectStateEntry so you can determinate if it's relationship or entity).

I tested out with with your example when relationship is changed the way you do

myEmployee.Department = myObjectContext.Department.Where("it.DepartmentName = 'Accounting'").First()

and I find out by calling GetObjectStateEntries for each possible EntityState that one ObjectStateEntry is added with state Added:

myObjectContext.ObjectStateManager.GetObjectStateEntries(System.Data.EntityState.Added)

Now, you can peek at the current values of the state entry to see if they match the ends of the relationship (not nice). However, it's a bit complicated and I'm not sure if it's going to meet your needs in every case.

C# – input string is not in a correct format

You're concatenating the strings and then trying to convert that one result into a double. So for results of 75.6, 92.1, 56.3 78.2 and 72.3 you'd end up trying to parse "75.692.156.378.272.3".

Parse each value and then sum them.

However, I would strongly recommend that you use decimal for this instead of double. You should also consider using TryParse instead of Parse so that you can handle user input errors gracefully. Here's the solution sticking with Parse:

public decimal AveragePercentage()
{
    decimal sum = decimal.Parse(tbEnglish.Text) +
                  decimal.Parse(tbUrdu.Text) +
                  decimal.Parse(tbPhysics.Text) +
                  decimal.Parse(tbChemistry.Text) +
                  decimal.Parse(tbMaths.Text);
    return sum / 5m;
}

Out of interest, in your original code why are you dividing by 500 and then multiplying by 100? Why not just divide by 5 (as mine does now that I've noticed what was going on)?

As a side note, it's very important to differentiate between compile-time errors and execution-time errors. It wasn't the compiler saying that the input string wasn't in the correct format - it was the Convert.ToDouble method, at execution time. In this case it was relatively obvious, but in other situations we could have been chasing our tails for a while trying to find a compile-time problem when it was actually failing at execution time.