Jest Mocking: Overriding Internal Component Props Without Changing Your Code Need to modify a React Native component’s internal behavior for testing? Instead of exposing test-specific props through your component API, mock the dependency directly. Sometimes tests need to control internal behavior of third-party components without modifying your production code. This pattern lets you override any prop or implementation detail while keeping the original component as a base. jest.mock('react-native', () => { const ActualRN = jest.requireActual('react-native'); // Use defineProperty to properly override getter-based exports Object.defineProperty(ActualRN, 'FlatList', { value: (props) => <ActualRN.FlatList {...props} initialNumToRender={props.data?.length} />, writable: true, // Allows Jest to overwrite this mock if needed configurable: true // Essential: lets Jest reset mocks between tests }); return ActualRN; // Preserves all other React Native components }); The key is Object.defineProperty, which safely overrides components exported as getters (like FlatList) while preserving React Native’s module structure. Unlike direct assignment that fails silently on getter properties, this method properly replaces the component definition. ...
Why a News Aggregator? I’ve been wanting to experiment with hybrid rendering in Next.js—mixing server-side rendering (SSR) for SEO-critical pages and client-side rendering (CSR) for dynamic filters. A news aggregator felt like the perfect use case: SSR for fast-loading, crawlable homepage headlines. CSR for real-time search/filtering as users tweak their queries. Instead of building a custom backend, I’m using the NewsAPI—a free API with global news data—to focus on the frontend architecture. But first, let’s see what the API actually offers! ...
How To Test an AsyncStorage Insert in React Native In a React Native app async storage any developer would eventually encounter this issue: testing a function that saves data to @react-native-async-storage/async-storage. The library itself doesn’t need to be tested; you want to test that your code calls the library correctly with the right data. A typical pattern is to have a service or a wrapper that encapsulates your storage logic. Let’s say you have a method like this that takes an object does things with it and finally saves it to storage: ...
Testing Zustand Stores Against Interfaces, Not Implementations In my previous previous article, I showed how to test a concrete IDataStore implementation that uses @react-native-async-storage/async-storage. But what about the code that consumes this interface? Today I want to share how I test my Zustand store to ensure it works correctly with any storage implementation—whether it’s AsyncStorage, SQLite, or a future web API. The beauty of this approach is that once you have a well-tested interface like IDataStore, testing the consumers becomes remarkably straightforward. You’re no longer testing against a specific storage implementation, but against a contract. ...