Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

jest-circus async tests #3819

Closed
wants to merge 1 commit into from
Closed

Conversation

aaronabramov
Copy link
Contributor

makes integration_tests/__tests__/jasmine_async-test.js pass.

  • AfterAll hook will not affect individual tests, but rather throw a global error that will fail the whole test file
  • BeforeAll failure results in one error being added to all dependent tests
  • Adds a test utility for testing jest-circus in isolation
  • timeouts can be passed to test/*Each/*All as a last argument
  • test.concurrent

@@ -43,6 +43,32 @@ const initialize = ({
global.fit = global.it.only;
global.fdescribe = global.describe.only;

global.test.concurrent = (
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i'm not including test.concurrent into jest-circus as a core functionality. In the current state it's never going to work properly (can't use certain matchers/hooks/proper .skip/.only/etc).
I also think we shouldn't document it either. It will be harder to reimplement it properly in the future if people start using it

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we could actually make a breaking change to test.concurrent to pass the context as first argument (rather than "done") like we were planning to do, that way we could make it work properly with state.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there's too many changes that need to be made before we can do that.
it's easier to keep it as it is right now and we'll focus on redesigning it later

|};

export type TestStatus = 'pass' | 'fail' | 'skip';
export type TestStatus = 'skip' | 'done';
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i removed fail status, since it's a derived value that can be calculated from test.errors.length.
All we need to know is whether it was skipped or finished running

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how about 'skip' | 'complete' then? Any other words instead of 'done'?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

'finish' maybe?

@cpojer cpojer changed the title jest-cirtus async tests jest-circus async tests Jun 20, 2017
// failing before hook
beforeAll(() => {
return new Promise(resolve => setTimeout(resolve, 100));
}, 10);
}, 11);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is it 11 now?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

easier to find in the console :)


'use strict';

const testEventHandler = (event, state) => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is really nice, I love how you are testing this. Could we make it a bit more generic somehow so that we don't have to keep this file in sync, though?

const TEST_EVENT_HANDLER_PATH = path.resolve(__dirname, './test_event_handler');

const runTest = (source: string) => {
const tmpFilename = path.join(os.tmpdir(), 'circus-test-file.js');
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we write this into tmp?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is the safest, but not the most pleasant way of writing files.
I was thinking about creating a gitignored directory (files_for_integration_tests) and write everything there, so it's easy to cd into the dir and see what's up in there

`"currentDescribeBlock" has to be there since we're finishing its definition.`,
);
}
invariant(currentDescribeBlock, `currentDescribeBlock mest to be there`);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

mest? What?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think it's something in between jest, must and has. i can't spell :'(

if (currentDescribeBlock.parent) {
state.currentDescribeBlock = currentDescribeBlock.parent;
}
break;
}
case 'add_hook': {
const {currentDescribeBlock} = state;
const {fn, hookType: type} = event;
currentDescribeBlock.hooks.push({fn, type});
const {fn, hookType: type, timeout} = event;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I like the aliasing. Why do we need to rename hookType to type?

@cpojer
Copy link
Member

cpojer commented Jun 20, 2017

Looks good to me as long as it matches Jasmine except for afterAll. Not able to give the full 100% proper review because I'm technically on vacation, so would love it if @rogeliog or @thymikee could take a look too.

Copy link
Contributor

@rogeliog rogeliog left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks really good overall, just some small comments

@@ -0,0 +1,75 @@
/**
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is really nice!

const {type} = hook;

if (type === 'beforeAll') {
invariant(describeBlock, 'always present for `*All` hooks');
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need to add a prefix to the message? Similar to the contentBlock invariant message

// too complicated, so we'll consider them to be global.
state.unhandledErrors.push(error);
} else {
invariant(test, 'always present for `*Each` hooks');
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need to add a prefix to the message? Similar to the contentBlock invariant message

break;
}
case 'test_skip': {
event.test.status = 'skip';
break;
}
case 'test_failure': {
event.test.status = 'fail';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we not need the fail status anymore?


const test = (testName: TestName, fn?: TestFn) =>
dispatch({fn, name: 'add_test', testName});
const test = (testName: TestName, fn?: TestFn, timeout?: number) =>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NIT: line 37 uses timeout: ?number instead of timeout?: number

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that's expected though! :)
in this function timeout is optional, and on line37, it's always passed, but can be null

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it

@github-actions
Copy link

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 13, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants