From 644228008531ade6b29189fec9e53b532118b543 Mon Sep 17 00:00:00 2001
From: Tatenda <31291528+rideam@users.noreply.github.com>
Date: Thu, 27 Feb 2025 13:37:07 +0200
Subject: [PATCH] link to fusionauth

---
 astro/src/content/blog/why-mocking-sucks.mdx | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/astro/src/content/blog/why-mocking-sucks.mdx b/astro/src/content/blog/why-mocking-sucks.mdx
index 9c782eb0fc..0f7773d1cd 100644
--- a/astro/src/content/blog/why-mocking-sucks.mdx
+++ b/astro/src/content/blog/why-mocking-sucks.mdx
@@ -136,7 +136,7 @@ Let's see how mocking a Firebase service and using the Firebase Emulator Suite d
 
 A common approach to testing Firebase authentication and Firestore interactions is to mock the Firebase Admin SDK. Below is an example of how developers typically do this in Python.
 
-<RemoteCode url="https://raw.githubusercontent.com/ritza-co/fusionauth-example-firebase-mock-testing-vs-emulation/refs/heads/main/firebase_test_with_mocking.py" lang="python"  />
+<RemoteCode url="https://raw.githubusercontent.com/fusionauth/fusionauth-example-firebase-mock-testing-vs-emulation/refs/heads/main/firebase_test_with_mocking.py" lang="python"  />
 
 While this approach allows for isolated testing, it introduces several problems:
 
@@ -176,7 +176,7 @@ firebase emulators:start
 
 With Firebase running locally, you can modify the authentication and Firestore functions to connect to the emulator instead of mocking API calls.
 
-<RemoteCode url="https://raw.githubusercontent.com/ritza-co/fusionauth-example-firebase-mock-testing-vs-emulation/refs/heads/main/firebase_test_with_emulator.py" lang="python"  />
+<RemoteCode url="https://raw.githubusercontent.com/fusionauth/fusionauth-example-firebase-mock-testing-vs-emulation/refs/heads/main/firebase_test_with_emulator.py" lang="python"  />
 
 The tests can reflect production-like conditions, catching issues like authentication changes, security rule enforcement, and API updates. 
 
@@ -192,7 +192,7 @@ To see how effective a real dev server can be, let's write a mock that simulates
     
 Here's how you might mock the login in Python:
 
-<RemoteCode url="https://raw.githubusercontent.com/ritza-co/fusionauth-example-mock-testing-vs-dev-server/refs/heads/main/fusionauth_test_with_mocking.py" lang="python"  />
+<RemoteCode url="https://raw.githubusercontent.com/fusionauth/fusionauth-example-mock-testing-vs-dev-server/refs/heads/main/fusionauth_test_with_mocking.py" lang="python"  />
 
 The `fusionauth_login` function simulates a login request to FusionAuth's `/api/login` endpoint. It handles various responses — success, incorrect credentials, locked accounts, and unexpected errors. The unit tests use `unittest.mock.patch` to replace real API calls, ensuring tests pass without needing a live FusionAuth server.
 
@@ -214,7 +214,7 @@ A [Kickstart](/docs/get-started/download-and-install/development/kickstart) file
 
 To create a test case that registers a user, the Kickstart file might look like the example below.
 
-<RemoteCode url="https://raw.githubusercontent.com/ritza-co/fusionauth-example-mock-testing-vs-dev-server/refs/heads/main/fusionauth/kickstart/kickstart.json" lang="json"  />
+<RemoteCode url="https://raw.githubusercontent.com/fusionauth/fusionauth-example-mock-testing-vs-dev-server/refs/heads/main/fusionauth/kickstart/kickstart.json" lang="json"  />
 
 This code declares variables to avoid repetition, and then defines an API key. It then executes a series of requests to:
 
@@ -259,7 +259,7 @@ You can further customize the services by editing the `docker-compose.yml` and `
 
 Now, you can rewrite the tests without mocking the FusionAuth API.
 
-<RemoteCode url="https://raw.githubusercontent.com/ritza-co/fusionauth-example-mock-testing-vs-dev-server/refs/heads/main/fusionauth_test_with_dev_server.py" lang="python"  />
+<RemoteCode url="https://raw.githubusercontent.com/fusionauth/fusionauth-example-mock-testing-vs-dev-server/refs/heads/main/fusionauth_test_with_dev_server.py" lang="python"  />
 
 Integration tests run against a real authentication service within the same network as the application, replicating production-like conditions. The authentication flow is validated end-to-end, ensuring that security headers, and real response times are properly accounted for before deployment.