Add jest and react testing library tests for victory-line and victory-area

[becca-bailey]

This is some initial work to switch over tests from Karma + enzyme to Jest + RTL. This adds new tests, but doesn't delete the original tests just yet.

Completed packages:

• victory-line
• victory-area

Related issue: #2195

To run jest tests:

yarn nps jest

OR

yarn nps jest.native

To pick up code changes in Victory packages, this test command will need to be run concurrently with yarn nps watch.

[ryan-roemer]

So, there are two things really:

1. Build all lib and test code when running tests.
2. Build only test code when running tests. For lib code that means running a separate watch to rebuild or one-off build.

I think No. 2 is the way to go.

And for Jest TEST_MODULE doesn't really apply. And for Karma, it has very little actual speed impact. The thing that does now massively speed up Karma in my d3 branch is that I only use already build lib code and remove all transpiling and inclusion of source code.

[becca-bailey]

@ryan-roemer Oops, I meant to edit my original question and accidentally deleted it! Anyway, I'm also looking into babel-jest which might give us some additional integration between our build step and jest watch mode. I agree that #2 makes more sense!

[ryan-roemer]

@becca-bailey Cool! And if the jest tests run fast enough on their own, then we maybe don't even need to heavily optimize for jest watch. (And jest watch should be fine watching with <pkg>/es same as <pkg>/src for auto-rerunning changes).

[becca-bailey]

@ryan-roemer That's a good point - for now running yarn nps watch concurrently with jest --watch works well!

[becca-bailey]

Any objections to merging in new tests as we go rather than waiting until they are all completed?

[becca-bailey]

This is a minor change to the user-provided props that mimics the API of other Victory props and allows us to pass in a function that evaluates the props.

For example:

<VictoryLine aria-label={props => props.label} />

I added this small change to this PR because it was useful for testing, but I will make a note to add some additional documentation around this in a separate PR.

[becca-bailey]

This is kind of a hacky solution that allows us to test the rendered data, since we're no longer able to directly access props with Enzyme (for a good reason!).

I might do a bit of research to see if there are better approaches to testing rendered data in data visualization, since an automated test suite can't easily test things like is the line going up or down the same way we could test it visually.

[becca-bailey]

It's also worth asking whether we should still be testing things like data ordering at the integration test level, or whether we should just unit test the helper functions.

[becca-bailey]

I have some outstanding questions on how we want to approach some of these tests, but since this PR is making minimal code changes, I am okay merging this as-is as a jumping off point for future work. From there, we can re-evaluate which tests are most useful and make changes as needed.