## Testing the NFT Purchase Flow and Event Indexing This lesson demonstrates testing the crucial "buy" functionality within our full-stack NFT marketplace. We will walk through the process of purchasing an NFT using the frontend interface, interacting with MetaMask, and observing how our off-chain indexer detects the purchase event on the blockchain to update the application state, ultimately removing the purchased item from the marketplace view. **Initial Marketplace State** We begin with our NFT marketplace application running locally (`localhost:3000`). The user interface displays several NFTs available for purchase. In this example, we see four distinct NFTs (Tokens #3, #2, #1, and #0), each listed with a price of 10.0000 USDC (represented by a mock token, MTToken, in this development environment). **Attempting an NFT Purchase: A Failure Scenario and Debugging** Let's simulate a user attempting to buy "Token #3". 1. **Navigate to Buy Page:** Clicking on "Token #3" takes the user to its dedicated purchase page. This page displays details like the NFT's contract address, Token ID (3), the seller's address, and importantly, an "Approve Payment Token" button. 2. **Connect Wallet:** The user connects their wallet using MetaMask, initially selecting an account ("Anvil5"). 3. **ERC20 Approval:** Since the purchase uses an ERC20 token (USDC/MTToken), a two-step process is required. First, the user must grant the marketplace smart contract permission to spend the required amount of tokens on their behalf. Clicking "Approve Payment Token" triggers a MetaMask prompt requesting a "Spending cap" – in this case, allowing the contract to spend 10 MTToken. The user confirms this transaction. 4. **Initiate Purchase:** Once the approval transaction is confirmed, the UI updates ("Payment token approved!"), and the button changes to "Buy Now". The user clicks "Buy Now". 5. **Transaction Confirmation:** MetaMask prompts again, this time for the actual `buyItem` transaction, transferring the tokens and the NFT. The user confirms. 6. **Observe Failure:** The UI shows a "Waiting for purchase transaction..." message. However, switching to the terminal running our indexer service reveals an error: `Error: reverted with custom error...`. The blockchain transaction has failed. 7. **Debugging:** The reason for the failure is identified: the selected MetaMask account ("Anvil5") does not possess the 10 USDC/MTToken required to complete the purchase. This highlights a common issue – ensuring the interacting wallet has sufficient funds (both for gas fees and the payment token itself). 8. **Resolution:** The user switches their active MetaMask account to one that holds sufficient funds ("Anvil10"). **Executing a Successful NFT Purchase** Now, using the "Anvil10" account with adequate funds, we repeat the purchase process for "Token #3": 1. **Approve Token:** On the Token #3 buy page, click "Approve Payment Token" and confirm the spending cap request in MetaMask. 2. **Buy NFT:** Once approved, click "Buy Now" and confirm the main purchase transaction in MetaMask. 3. **Transaction Success:** This time, the transaction succeeds on the blockchain. The UI reflects this, displaying a confirmation message like "Congratulations! You have successfully purchased this NFT..." before automatically redirecting the user back to the marketplace homepage. **The Indexer's Role in Updating the UI** How does the frontend know the NFT is sold? This is where our indexer service is critical. 1. **Event Emission:** The successful `buyItem` transaction on the smart contract emitted an `ItemBought` event. 2. **Event Detection:** Our indexer service, constantly monitoring the blockchain for specific events defined in its configuration (including `ItemBought`, `ItemCanceled`, and `ItemListed`), detects this newly emitted `ItemBought` event for Token #3. 3. **Processing and Database Update:** Upon detecting the event, the indexer processes it. This typically involves updating an off-chain database (which the indexer manages) to mark Token #3 as sold or remove it from the table of actively listed items. We can see confirmation of this in the indexer's logs, which now show a message similar to: `INFO NftMarketplace:ItemBought - INDEXED 1 events...`. 4. **Frontend Data Refresh:** When the user is redirected to the homepage, the frontend application fetches the list of available NFTs. It queries the backend API, which in turn reads from the database updated by the indexer. 5. **UI Update Verification:** Because the indexer updated the database to reflect the sale, the data fetched by the frontend no longer includes Token #3. Consequently, the marketplace homepage now correctly displays only the remaining NFTs (Tokens #2, #1, and #0). Token #3 has been successfully removed from the listing. **Reinforcing the Pattern** To further verify the system, the process is repeated for another NFT, "Token #1". The user (with the funded "Anvil10" account) approves the token spend and executes the "Buy Now" transaction. The purchase is successful, the indexer logs the `ItemBought` event, the database is updated, and upon returning to the homepage, Token #1 is also gone, leaving only Tokens #2 and #0 listed. **Key Concepts Demonstrated** This walkthrough illustrates several core concepts in full-stack web3 development: * **Event Indexing:** Using an off-chain service to listen for and react to on-chain smart contract events (`ItemBought`). * **Event-Driven Architecture:** The application's state (available NFTs) is updated based on blockchain events captured by the indexer. * **Decoupling:** The indexer decouples the frontend from needing to directly query the blockchain for complex state changes, leading to a more performant and scalable UI. * **ERC20 Approval Pattern:** The standard two-step process (`approve` then `transferFrom` or equivalent) required when a smart contract needs to spend a user's ERC20 tokens. * **Full-Stack Interaction:** The interplay between the frontend UI, wallet (MetaMask), smart contract, blockchain events, and the off-chain indexer service. * **Debugging:** Encountering and resolving a common transaction failure due to insufficient funds. **Note on Testing Efficiency** Manually testing this entire flow (approve, buy, check UI update) for every scenario can be time-consuming. As mentioned in the video, leveraging end-to-end testing frameworks like Playwright is highly recommended to automate these checks, ensuring reliability and saving development time. **Conclusion** You have now successfully tested the end-to-end NFT purchase flow within the marketplace. This exercise demonstrates the critical role of the event indexer in maintaining an accurate and responsive user interface by efficiently processing blockchain events and updating the application's off-chain state representation. This indexed data allows the frontend to quickly display the current list of available NFTs without directly querying the blockchain for every listed item.