Add test exercising public API to test BeforeInputEventPlugin + FallbackCompositionState

[GordyD]

Part of the effort to refactor tests to use the Public API #11299

• I've adopted a similar approach to the existing test for BeforeInputEventPlugin
• These tests simulate events and then assert the event handler for onBeforeInput is fired or not fired based on the test conditions
• The test scenarios are tested against IE11, Webkite and Presto environment simulations
• I've encorporated what I understand to be the functionality in the FallbackCompositionState test

There are a few more test cases to add. However, the main reason I'm putting this diff up is to:

• get feedback on approach
• get community support on resolving a failing test I'm encountering when testing the expected behavior of the compositionend fallback behavior on a contenteditable - right now I avoid running these test cases by avoiding the failing tests when simulating an environment which relies on the fallback statetestContentEditableComponent(environments[2], scenarios.splice(0, 5));

[gaearon]

The approach seems fine to me, we can always refactor later if needed.

I'm way out of my depth re: the second question so I hope you can carry this through and figure it out.

[GordyD]

Update: Will circle back around onto this at some point this week.

[gaearon]

Awesome, thank you!

[GordyD]

Finally got the chance to look back into this. After rebasing onto master it looks like support for browsers using the presto engine (Opera Mini) have been removed so I've removed any specific testing for that browser in my tests too. I still need to simulate a similar environment though (no composition event support) to test the behavior of FallbackCompositionState so I've left a test case in for that. (I've omitted testing FallbackCompositionState on a contenteditable though as the fallback behavior for triggering compositionstart does not work as expected - keydown and keyup events are mapped as keypress events(??) - which means the fallback logic will not be triggered - not sure if this a blocker to accepting this or not)

My approach:

I went through the following steps to check out coverage of the tests I've written whilst watching the tests:

• comment out 'BeforeInputEventPlugin' in DOMEventPluginOrder causes all tests to fail
• comment out blocks of in BeforeInputEventPlugin to check for corresponding failing tests
• comment out blocks in FallbackCompositionState to check for corresponding failing tests

Things of note in BeforeInputEventPlugin.js:

• I can comment out the body of getCompositionEventType, or comment out line 207, with no failing tests - it seems under the conditions where this function is called - the extraction of a onBeforeInput event is handled is by both the underlying extraction functions - so either I need another test case to exercise this path, or this code is redundant?
• I can comment out lines 226-228 with no failing tests even though the code path is exercised - I wonder if this redundant or not.
• commenting out accumulateTwoPhaseDispatches in either extractXXX function does not break my tests - I'm not sure how to protect against this - any pointers would be welcome here :)

@gaearon any thoughts on how to proceed? I think we have pretty decent coverage here with testing through the public API.

N.B I've also removed the no longer needed tests exercising the internal API.

[gaearon]

LGTM, thanks!