.

package.json

@@ -9,7 +9,7 @@
     "url": "https://www.github.com/callstack/react-native-testing-library.git"
   },
   "homepage": "https://oss.callstack.com/react-native-testing-library",
-  "author": "Michał Pierzchała <thymikee@gmail.com> (https://github.com/thymikee), Maciej Jastrzębski <mdjastrzebski@gmail.com> (https://github.com/mdjastrzebski)",
+  "author": "Maciej Jastrzębski <mdjastrzebski@gmail.com> (https://github.com/mdjastrzebski), Michał Pierzchała <thymikee@gmail.com> (https://github.com/thymikee)",
   "contributors": [
     "Augustin Le Fèvre <augustin.le-fevre@klarna.com> (https://github.com/AugustinLF)",
     "Pierre Zimmermann <pierrez@nam.tech> (https://github.com/pierrezimmermannbam)",

website/docs/14.x/docs/advanced/testing-env.mdx

@@ -25,11 +25,13 @@ Instead, RNTL uses [Test Renderer](https://github.com/mdjastrzebski/test-rendere
 Using Test Renderer has trade-offs:
 
 Benefits:
+
 - Tests run on most CIs (Linux, etc) without a mobile device or emulator
 - Faster test execution
 - Light runtime environment
 
 Limitations:
+
 - Tests don't execute native code
 - Tests are unaware of view state managed by native components, e.g., focus, unmanaged text boxes, etc.
 - Assertions don't operate on native view hierarchy

website/docs/14.x/docs/guides/faq.mdx

@@ -16,12 +16,14 @@ You can learn more about our testing environment [here](/docs/advanced/testing-e
 This approach has benefits and limitations:
 
 Benefits:
+
 - Tests most of the logic of regular React Native apps
 - Runs tests on any OS supported by Jest or other test runners, e.g., on CI
 - Uses fewer resources than full runtime simulation
 - Works with Jest fake timers
 
 Limitations:
+
 - Cannot test native features
 - May not perfectly simulate certain JavaScript features, but we're working on it