Add warning and failing test decorators

[Latropos]

Summary

After this PR we are going to support the following API:

Describe:

• describe("Name of the test suite", ()=>{})
• describe.skip("Name of the test suite", ()=>{})
  • Skip test suite
• describe.only("Name of the test suite", ()=>{})
  • Run only test cases and test suite(s) with only decorator

Test:

• default
  • test("Name of the test suite", ()=>{})
  • test.each([1,2,3])("Name of the test suite", ()=>{})
• skip ⏭️ - skip test case(s)
  • test.skip("Name of the test suite", ()=>{})
  • test.skip.each([1,2,3])("Name of the test suite", ()=>{})
• only - run only test case(s) and suite(s) with only decorator
  • test.only("Name of the test suite", ()=>{})
  • test.only.each([1,2,3])("Name of the test suite", ()=>{})
• warn ⚠️ - expect console.warn to be called
  • test.warn("Name of the test suite", "Expected error message", ()=>{})
  • test.warn.each([1,2,3])("Name of the test suite", "Expected error message", ()=>{})
• failing - expect error to be thrown
  • test.failing("Name of the test suite", "Expected error message", ()=>{})
  • test.failing.each([1,2,3])("Name of the test suite", "Expected error message", ()=>{})

Test plan

[szydlovsky]

Looks good, left just one small comment 😄

[piaskowyk]

Suggested change

	return <Text>Something went wrong.</Text>;
	return <Text>Detected exception during component rendering.</Text>;

[piaskowyk]

What will happen if someone doesn't add <ErrorBoundary> and a component throws an error? Perhaps we should consider adding it by default inside the RuntimeTestsRunner component.

[Latropos]

What will happen if someone doesn't add and a component throws an error?

The tests will stop, you have to somehow catch all the errors to keep the tests execution.

Perhaps we should consider adding it by default inside the RuntimeTestsRunner component.

I was considering it. However our test cases should consist of simple scenarios, and such a wrapper would modify the rendered components. Sometimes we add new tests after fixing bugs, and with a wrapper we can't be sure that all the bugs are going to be reproducible

[piaskowyk]

The expect function should be utilized by the user during testing, not in our internal logic. This functionality is not the responsibility of the expect method. We can simply use a single shared value for it instead of a callTracker.

[piaskowyk]

Do you ever restore original implementation of console.warn?

[Latropos]

No, since you have to reload the app to re-run the tests and it resets it.

[piaskowyk]

Why did you choose test.warn syntax instead of something similar to Jest syntax? I mean:

test('Invalid mass and stiffness, config is { mass: -40, stiffness: -400 }', async () => {
  const result = await render(<AnimatedComponent animateFrom={30} animateTo={300} config={{ mass: -40, stiffness: -400 }} />);
  expect(result).toThrow('[Reanimated] Invalid spring config...', mode=WARNING);
});

[Latropos]

In jest there are two ways to test errors,

• expect(() => doSomething() ).toThrow( ...) LINK
• test.failing LINK
  I've chosen the second one since it seemed simpler. Also there is no in-built way to check console.warn, you just have to use some function tracker, but I believe that having sth similar to error tests would be beneficial

[piaskowyk]

Do we ignore all exceptions? 🤔

[piaskowyk]

it could be just a simple sharedValue (makeMutable) instead of using callTrucker