docs(angular): 📝 add angular core cookbook

Author: yjaaidi

.firebaserc

@@ -1,5 +1,12 @@
 {
   "projects": {
     "default": "marmicode-cookbook"
+  },
+  "targets": {
+    "marmicode-cookbook": {
+      "hosting": {
+        "cookbook": ["marmicode-cookbook"]
+      }
+    }
   }
 }

.github/workflows/test.yml

@@ -38,16 +38,15 @@ jobs:
       - run: bunx nx-cloud record -- nx format:check
       - run: bunx nx affected -t build lint test e2e
       - name: 🔐 Set up service account
-        if: github.ref == 'refs/heads/main'
         env:
           FIREBASE_SERVICE_ACCOUNT_MARMICODE_COOKBOOK: ${{ secrets.FIREBASE_SERVICE_ACCOUNT_MARMICODE_COOKBOOK }}
         run: |
           echo $FIREBASE_SERVICE_ACCOUNT_MARMICODE_COOKBOOK > ~/.firebase-sa.json
           echo "GOOGLE_APPLICATION_CREDENTIALS=$HOME/.firebase-sa.json" >> "$GITHUB_ENV"
       - name: 🚀 Deploy
-        if: github.ref == 'refs/heads/main'
         run: bunx nx affected -t deploy --no-agents
-
+      - name: 🔍 Smoke test
+        run: bunx nx run-many -t smoke
       - uses: actions/upload-artifact@v4
         if: ${{ !cancelled() }}
         with:

.gitignore

@@ -25,4 +25,5 @@ yarn-error.log*
 .nx/cache
 .nx/workspace-data
 .firebase
-vite.config.*.timestamp*
+vite.config.*.timestamp*
+vitest.config.*.timestamp*

apps/cookbook/docs/angular-testing/00-introduction/index.md

@@ -0,0 +1,25 @@
+---
+title: Introduction
+slug: /angular/testing
+---
+
+# Angular Testing Cookbook
+
+import { useDocsSidebar } from '@docusaurus/plugin-content-docs/client';
+import DocCardList from '@theme/DocCardList';
+import { ExternalLink } from '@site/src/components/external-link';
+
+This cookbook is the complementary resource to the <ExternalLink href="https://courses.marmicode.io/courses/pragmatic-angular-testing" medium="in-article" content="angular-testing-intro">Pragmatic Angular Testing</ExternalLink> course.
+
+It's for Angular developers who want to build a **pragmatic testing strategy** — **in opposition to dogmatic approaches** such as:
+
+- _"your unit-test is not a unit-test"_
+- _"let's mock everything"_
+- _"let's go full E2E"_
+- _"let's target 100% coverage"_
+
+You'll learn how to write tests that are fast, readable, and resilient. You'll escape the cycle of bloated mocks and brittle end-to-end tests that slow down development.
+
+Many teams only realize the cost of skipping these practices after months or years of pain. Lucky you! You found this resource, so you won't have to.
+
+<DocCardList items={useDocsSidebar('angular-testing').items.slice(1)}/>

apps/cookbook/docs/angular/01-testing/01-beyond-unit-vs-integration/index.mdx renamed to apps/cookbook/docs/angular-testing/01-beyond-unit-vs-integration/index.mdx

@@ -1,6 +1,6 @@
 ---
 title: Beyond Unit vs. Integration
-slug: /angular/beyond-unit-vs-integration
+slug: /angular/testing/beyond-unit-vs-integration
 toc_max_heading_level: 4
 ---
 
@@ -156,24 +156,24 @@ They are **either**:
 
 Given Wide test properties, one might think that they should simply be avoided. However, Wide tests have their own advantages:
 
-- They are more [symmetric to production](../../02-glossary.md#symmetric-to-production), and [predictive](../../02-glossary.md#predictive), thus more reassuring.
-- They are more [structure-insensitive](../../02-glossary.md#structure-insensitive) _(e.g. you can refactor your code without breaking them)_.
+- They are more [symmetric to production](../06-glossary.md#symmetric-to-production), and [predictive](../06-glossary.md#predictive), thus more reassuring.
+- They are more [structure-insensitive](../06-glossary.md#structure-insensitive) _(e.g. you can refactor your code without breaking them)_.
 
 ## ⚖️ Comparing Narrow and Wide Tests {#comparing-narrow-and-wide-tests}
 
-| Property                                                                | Narrow Tests          | Wide Tests            |
-| ----------------------------------------------------------------------- | --------------------- | --------------------- |
-| **[Speed](#fast)**                                                      | ⚡️ Fast              | 🐢 Slow               |
-| **[Isolation](#easy-to-isolate-and-parallelize)**                       | 🏝️ Easy to isolate    | 🔗 Harder to isolate  |
-| **[Cognitive Load](#low-cognitive-load)**                               | 😌 Low cognitive load | 🤯 Harder to diagnose |
-| **[Precision](../../02-glossary.md#precise-tests)**                     | Higher Precision      | Lower Precision       |
-| **[Production-Symmetry](../../02-glossary.md#symmetric-to-production)** | Lower Symmetry        | Higher Symmetry       |
-| **[Structure-Sensitivity](../../02-glossary.md#structure-insensitive)** | Higher Sensitivity    | Lower Sensitivity     |
+| Property                                                             | Narrow Tests          | Wide Tests            |
+| -------------------------------------------------------------------- | --------------------- | --------------------- |
+| **[Speed](#fast)**                                                   | ⚡️ Fast              | 🐢 Slow               |
+| **[Isolation](#easy-to-isolate-and-parallelize)**                    | 🏝️ Easy to isolate    | 🔗 Harder to isolate  |
+| **[Cognitive Load](#low-cognitive-load)**                            | 😌 Low cognitive load | 🤯 Harder to diagnose |
+| **[Precision](../06-glossary.md#precise-tests)**                     | Higher Precision      | Lower Precision       |
+| **[Production-Symmetry](../06-glossary.md#symmetric-to-production)** | Lower Symmetry        | Higher Symmetry       |
+| **[Structure-Sensitivity](../06-glossary.md#structure-insensitive)** | Higher Sensitivity    | Lower Sensitivity     |
 
 :::tip Narrow Tests Foster Good Design
 It is easier to write Narrow tests for well-designed code with clear separation of concerns, and the right abstractions where we can easily replace dependencies with test doubles. Therefore **Narrow tests are more likely to foster good design**.
 
-On the other hand, Over-Narrow tests can lead to [over-specification](../../02-glossary.md#over-specification) and make tests more [structure-sensitive](../../02-glossary.md#structure-insensitive) and brittle.
+On the other hand, Over-Narrow tests can lead to [over-specification](../06-glossary.md#over-specification) and make tests more [structure-sensitive](../06-glossary.md#structure-insensitive) and brittle.
 :::
 
 ## Which one to choose?