-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
As a beer league hockey player, Given it's light outside, When I open the Wolfpack app, Then I see a light-themed app, So that it's easier on my eyes. As a beer league hockey player, Given it's dark outside, When I open the Wolfpack app, Then I see a dark-themed app, So that it's easier on my eyes. https://www.pivotaltracker.com/story/show/186950237 Some other notes: iOS uses [PlatformColor](https://reactnative.dev/docs/platformcolor)'s, while other platforms use regular [react native color keywords](https://reactnative.dev/docs/colors#color-keywords). Because of this, in order to test all the logic for a single color scheme (we use light), we needed to test the behavior on another platform (Android and web). The default platform that we'd been testing was iOS - only iOS. We now test on iOS and Android. We would have liked to have tested all of iOS, Android, and web, since we deploy all three, but we had [trouble getting MSW to work in the web environment](mswjs/msw#1786). We tried [the official solution in the docs](https://mswjs.io/docs/migrations/1.x-to-2.x#cannot-find-module-mswnode-jsdom) and several solutions mentioned in the issue page, linked above. None of those solutions worked well for us. In lieu of testing the web env, we're going to try to only do iOS specific things, and then any other logic that's used should be kept to work for both Android and the web environment, so that all the web environment features are still under test in the android test suite. The solution isn't ideal, but as long as we stick with this approach (and it'd be easy to forget or not do things this way, which is why it isn't ideal) all the specs should cover all scenarios in every environment. It's also worth noting that we decided not to test other color schemes (we only test light by default) because testing the dark color scheme seems like it won't add any value, unless we do [snapshot tests](https://jestjs.io/docs/snapshot-testing), which don't align well with the spirit of TDD (you write them after the fact) and would promote difficulting in refactoring (changing the <View> structure of a page (similar to changing the <div> structure of a webpage)) would cause a test to fail - which isn't what we're looking for in tests. We like to know that our feature specs still work after a change is made - which is to say we like to have confidence that our refactors don't change behavior, not that they don't change exactly _how_ features are implemented.
- Loading branch information
Showing
16 changed files
with
352 additions
and
166 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.