link to fusionauth

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.