Duplicate V2

[zephraph]

This PR consists of the follow changes:

1. duplicating v1 to v2
2. duplicating src/test/utils.ts to src/schema/v1/test/utils.ts and src/schema/v2/test/utils.ts. This was needed because each file specifies the schema to query.
3. Updating the import path to the correct test/utils file in both v1 and v2.
4. Updating incrementalMergeSchemas in src/lib/mergeSchemas to take in a schema. This was causing a test failure in src/schema/v2/__tests__/city.test.ts because it has a mock file that was being bypassed by stitching actually loading files from v1.

What this PR does not do:

• Wire up /v2 to anything
• Make any substantial or logical differences in v1 when compared to v2

It is, for all intents and purposes, a straight copy the the basic due diligence to ensure that tests are passing for both v1 and v2.

Once we merge this the sync battles begin.

[peril-staging]

New dependencies added: jest-junit.

jest-junit

Author: Jason Palmer

Description: A jest reporter that generates junit xml files

Homepage: https://github.com/jest-community/jest-junit#readme

Created	over 2 years ago
Last Updated	1 day ago
License	Apache-2.0
Maintainers	1
Releases	35
Direct Dependencies	jest-validate, mkdirp, strip-ansi and xml

README

jest-junit

A Jest reporter that creates compatible junit xml files

Installation

yarn add --dev jest-junit

Important Notice

In an upcoming major version 7.x jest-junit will no longer function as a testResultProcessor. It will only work as a jest reporter. See the docs just below this for how to transition your project.

Usage

In your jest config add the following entry:

{
  "reporters": [ "default", "jest-junit" ]
}

Then simply run:

jest

For your Continuous Integration you can simply do:

jest --ci --reporters=default --reporters=jest-junit

Usage as testResultsProcessor

In your jest config add the following entry:

{
  "testResultsProcessor": "jest-junit"
}

Then simply run:

jest

For your Continuous Integration you can simply do:

jest --ci --testResultsProcessor="jest-junit"

Configuration

jest-junit offers several configurations based on environment variables or a jest-junit key defined in package.json or a reporter option.
Environment variable and package.json configuration should be strings.
Reporter options should also be strings exception for suiteNameTemplate, classNameTemplate, titleNameTemplate that can also accept a function returning a string.

Environment Variable Name	Reporter Config Name	Description	Default	Possible Injection Values
JEST_SUITE_NAME	suiteName	name attribute of <testsuites>	"jest tests"	N/A
JEST_JUNIT_OUTPUT	output	File path to save the output.	"./junit.xml"	N/A
JEST_JUNIT_OUTPUT_DIR	outputDirectory	Directory to save the output.	null	N/A
JEST_JUNIT_OUTPUT_NAME	outputName	File name for the output.	"./junit.xml"	N/A
JEST_JUNIT_SUITE_NAME	suiteNameTemplate	Template string for name attribute of the <testsuite>.	"{title}"	{title}, {filepath}, {filename}, {displayName}
JEST_JUNIT_CLASSNAME	classNameTemplate	Template string for the classname attribute of <testcase>.	"{classname} {title}"	{classname}, {title}, {filepath}, {filename}, {displayName}
JEST_JUNIT_TITLE	titleTemplate	Template string for the name attribute of <testcase>.	"{classname} {title}"	{classname}, {title}, {filepath}, {filename}, {displayName}
JEST_JUNIT_ANCESTOR_SEPARATOR	ancestorSeparator	Character(s) used to join the describe blocks.	" "	N/A
JEST_JUNIT_ADD_FILE_ATTRIBUTE	addFileAttribute	Add file attribute to the output. This config is primarily for Circle CI. This setting provides richer details but may break on other CI platforms.	false	N/A
JEST_JUNIT_INCLUDE_CONSOLE_OUTPUT	includeConsoleOutput	Adds console output to any testSuite that generates stdout during a test run.	false	N/A
JEST_USE_PATH_FOR_SUITE_NAME	usePathForSuiteName	DEPRECATED. Use suiteNameTemplate instead. Use file path as the name attribute of <testsuite>	"false"	N/A

You can configure these options via the command line as seen below:

JEST_SUITE_NAME="Jest JUnit Unit Tests" JEST_JUNIT_OUTPUT="./artifacts/junit.xml" jest

Or you can also define a jest-junit key in your package.json. All are string values.

{
  ...
  "jest-junit": {
    "suiteName": "jest tests",
    "outputDirectory": ".",
    "outputName": "./junit.xml",
    "classNameTemplate": "{classname}-{title}",
    "titleTemplate": "{classname}-{title}",
    "ancestorSeparator": " › ",
    "usePathForSuiteName": "true"
  }
}

Or you can define your options in your reporter configuration.

// jest.config.js
{
	reporters: [
      "default",
    	[ "jest-junit", { suiteName: "jest tests" } ]
  ]
}

Configuration Precedence

If using the usePathForSuiteName and suiteNameTemplate, the usePathForSuiteName value will take precedence. ie: if usePathForSuiteName=true and suiteNameTemplate="{filename}", the filepath will be used as the name attribute of the <testsuite> in the rendered jest-junit.xml).

Examples

Below are some example configuration values and the rendered .xml to created by jest-junit.

The following test defined in the file /__tests__/addition.test.js will be used for all examples:

describe('addition', () => {
  describe('positive numbers', () => {
    it('should add up', () => {
      expect(1 + 2).toBe(3);
    });
  });
});

Example 1

The default output:

<testsuites name="jest tests">
  <testsuite name="addition" tests="1" errors="0" failures="0" skipped="0" timestamp="2017-07-13T09:42:28" time="0.161">
    <testcase classname="addition positive numbers should add up" name="addition positive numbers should add up" time="0.004">
    </testcase>
  </testsuite>
</testsuites>

Example 2

Using the classNameTemplate and titleTemplate:

JEST_JUNIT_CLASSNAME="{classname}" JEST_JUNIT_TITLE="{title}" jest

renders

<testsuites name="jest tests">
  <testsuite name="addition" tests="1" errors="0" failures="0" skipped="0" timestamp="2017-07-13T09:45:42" time="0.154">
    <testcase classname="addition positive numbers" name="should add up" time="0.005">
    </testcase>
  </testsuite>
</testsuites>

Example 3

Using the ancestorSeparator:

JEST_JUNIT_ANCESTOR_SEPARATOR=" › " jest

renders

<testsuites name="jest tests">
  <testsuite name="addition" tests="1" errors="0" failures="0" skipped="0" timestamp="2017-07-13T09:47:12" time="0.162">
    <testcase classname="addition › positive numbers should add up" name="addition › positive numbers should add up" time="0.004">
    </testcase>
  </testsuite>
</testsuites>

Example 4

Using the suiteNameTemplate:

JEST_JUNIT_SUITE_NAME ="{filename}" jest

<testsuites name="jest tests">
  <testsuite name="addition.test.js" tests="1" errors="0" failures="0" skipped="0" timestamp="2017-07-13T09:42:28" time="0.161">
    <testcase classname="addition positive numbers should add up" name="addition positive numbers should add up" time="0.004">
    </testcase>
  </testsuite>
</testsuites>

Example 5

Using classNameTemplate as a function in reporter options

// jest.config.js
{
  reporters: [
    "default",
      [
        "jest-junit",
        {
          classNameTemplate: (vars) => {
            return vars.classname.toUpperCase();
          }
        }
      ]
  ]
}

renders

<testsuites name="jest tests">
  <testsuite name="addition" tests="1" errors="0" failures="0" skipped="0" timestamp="2017-07-13T09:42:28" time="0.161">
    <testcase classname="ADDITION POSITIVE NUMBERS" name="addition positive numbers should add up" time="0.004">
    </testcase>
  </testsuite>
</testsuites>

Generated by 🚫 dangerJS against 3460706

[zephraph]

Heh, I don't know why I was thinking that this would be remotely easy. Tests were hanging/failing due to memory issues. I thought I could potentially alleviate this situation by pulling the tests out of the hokusai container. Our integration tests don't work outside of that environment. (Makes sense). Separated out the integration tests from the unit tests and we're still running into memory issues. Boo.

Here's the script I've been using to test memory usage in jest

node --expose-gc ./node_modules/.bin/jest --runInBand --logHeapUsage

We got a leak all right and it ain't pretty.

Here's a demonstration:

(It keeps growing from there)

I've got meh news and bad news. The meh news is that this actually happens in master too. The bad news is that because the number of tests have effectively doubled, we can't keep truckin' along with our memory sieve spewin' bytes like a bad breakfast.

We've gotta figure out what's up with this before moving on.

[zephraph]

The memory leak feels a lot like jestjs/jest#6814. There's a PR for it at jestjs/jest#8331 and a patch-package update linked from there that we could potentially test.

[ashkan18]

ayaya.. this kind of (i hope) explains why running MP tests kind of kills my laptop while its running. Great find!

[alloy]

Turned out to be a different type of leak in our own code #1848

[alloy]

Tested locally with Emission master, let’s do this 👍