🐛Add computed styles to fake win

[calebcordry]

While investigating test failures for #26447, I noticed that I would get a different number of tests each time when running test-runtime locally?!?

After investigation it appears many (all?) of the tests using fakeWin in this file would throw an error when the runtime eventually calls getComputedStyle. This PR adds this method to the fake win.

I think this was causing all sorts of weird behaviors, and likely that many tests were unintentionally being skipped due to the test runner borking. When I added the method it surfaced two obvious errors that must not have been run all this time :(

Also might be opening a can of worms here by exposing other uncaught errors in other test files that may be exposed after introduction of this method on fakeWin. Going to let travis run and see what happens. Looks like tests passed.

[calebcordry]

cc/ @rsimha who might have ideas about how to prevent things like this in the future.

[cramforce]

Good find. Could it be that you want
arguments[0].defaultView instead of window?

[calebcordry]

Maybe :) arguments[0] is the element here, so I tried arguments[0].ownerDocument.defaultView which points at the fake win, but it throws an Illegal invocation error.

[cramforce]

This would be expected to work when the element is from the actual window.

[rsimha]

many tests were unintentionally being skipped due to the test runner borking

I believe you hit #15658.

cc/ @rsimha who might have ideas about how to prevent things like this in the future.

This is a long standing issue that I've investigated from time to time. One thing I haven't explored yet, but mean to, is to check if your test suite is doing something asynchronous inside a describe block, but not inside a before, beforeEach, after, afterEach, or it. In other words, nothing async should happen inside the body of a describe block, but outside those well-known functions.

Let me know if you spot something in your tests that matches this antipattern.