test: add E2E tests for home page, header and footer components

[anushkaaaaaaaa]

Description:

I have added E2E tests using Cypress for the homepage, header and footer components to ensure proper functionality and rendering. These tests cover key aspects such as:

• Header: Verifying the presence of essential navigation links, the Async API logo, the star on Github button.
• Footer: Ensuring proper rendering of links and text visibility.
• Home Page: Verifying critical user workflows on the Home Page such as interaction with various links, buttons and logos.

Changes:

• Created test cases for the homepage header to check for correct rendering of links to pages present in the Header such as Roadmap, Case Studies and Blog.
• Added test cases for dropdowns present under Docs, Tools and Community pages.
• Added test cases for the footer to validate that links are rendered correctly.
• Added test cases for the homepage to verify user interaction with various components present.
• Also added test cases to verify links that redirect to different sites from the Home Page present on the Header.

Related Issues-:

• Implement E2E UI tests for the website critical flows #3671

Summary by CodeRabbit

• Tests
  • Expanded E2E coverage for the homepage with data-driven navigation to Blog, Docs, Case Studies, Tools, Community, and Roadmap plus many UI/content verifications (header/logo, GitHub star, Read the Docs, feedback link, cards and links).
  • Added header dropdown hover tests for Docs, Tools, and Community.
  • Added footer link validation for initiative, social, news, and Netlify links.
• Chores
  • Added reusable page objects, base helpers, and fixtures to standardize test data and navigation.

[netlify]

✅ Deploy Preview for asyncapi-website ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	b2aece8
🔍 Latest deploy log	https://app.netlify.com/projects/asyncapi-website/deploys/690e18fe1354600007ccce8f
😎 Deploy Preview	https://deploy-preview-4194--asyncapi-website.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[coderabbitai]

Walkthrough

Adds comprehensive Cypress E2E specs, page objects (base + per-page), JSON fixtures for homepage/footer, and a typed footer data module exporting initiative, social, news links and a netlify link for use in tests and the app.

Changes

Cohort / File(s)	Summary
Cypress E2E Specs cypress/header.cy.js, cypress/footer.cy.js, cypress/homepage.cy.js	Add header dropdown tests, footer link validation (data-driven), and an expanded/data-driven homepage navigation and UI assertions suite.
Cypress Page Objects — Base helpers cypress/pages/BaseHeaderPage.js, cypress/pages/BaseFooterPage.js	Add base utilities: visit, getElement, hoverElement, and a generic verifyLink helper for anchor existence/attributes.
Cypress Page Objects — Components cypress/pages/header.js, cypress/pages/Footer.js	Add Header PO (generic dropdown verifier + Docs/Tools/Community wrappers) and Footer PO (scoped footer link verification) extending base classes.
Cypress Page Objects — Pages cypress/pages/homepage.js, cypress/pages/BlogPage.js, cypress/pages/CaseStudiesPage.js, cypress/pages/CommunityPage.js, cypress/pages/DocsPage.js, cypress/pages/ToolsPage.js, cypress/pages/RoadmapPage.js	Add HomePage PO with navigation helpers and many UI verifiers; add per-page objects each exposing verifyPageLoaded().
Fixtures cypress/fixtures/homePageData.json, cypress/fixtures/footerPageData.json	Add structured fixtures for homepage content and footer links used by tests.
Footer Data Module components/footer/FooterData.ts	Add typed exports: initiativeLinks, socialMediaData, newsLinks, footerMiscData (netlifyLink) and composite footerData for app/tests.

Sequence Diagram(s)

sequenceDiagram
  autonumber
  actor Tester
  participant Spec as Cypress Spec
  participant HomePO as HomePage PO
  participant Router as App Router
  participant PagePO as Target Page PO

  Tester->>Spec: run "navigate to <Page>" test
  Spec->>HomePO: visit("/")
  Spec->>HomePO: goTo<Page>Page()
  HomePO->>Router: click nav link
  Router-->>PagePO: load page
  Spec->>PagePO: verifyPageLoaded()
  PagePO-->>Spec: assertion results

Loading

sequenceDiagram
  autonumber
  participant Spec as Cypress Spec
  participant HeaderPO as Header PO
  participant DOM as Navbar/Flyout

  Spec->>HeaderPO: visit("/")
  Spec->>HeaderPO: verify<Section>Dropdown()
  HeaderPO->>DOM: hover nav item ("Docs"/"Tools"/"Community")
  DOM-->>Spec: flyout visible assertion

Loading

sequenceDiagram
  autonumber
  participant Spec as Cypress Spec
  participant FooterPO as Footer PO
  participant DOM as <footer>

  Spec->>FooterPO: visit("/")
  loop for each link in (initiativeLinks, socialMediaData, newsLinks, netlify)
    Spec->>FooterPO: verifyFooterLink(href, label)
    FooterPO->>DOM: within(footer) find a[attr=href]
    DOM-->>Spec: visible + attribute (+ optional text)
  end

Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related PRs

• feat: initial cypress setup #4134 — also modifies and expands Cypress E2E scaffolding and homepage page objects/tests.

Suggested reviewers

• sambhavgupta0705
• derberg
• akshatnema
• quetzalliwrites
• devilkiller-ag
• Mayaleeeee
• asyncapi-bot-eve
• TRohit20

Poem

I hopped through headers, footer, and page,
Verified links on every stage.
Cards aligned and dropdowns bright,
Tests all green beneath moonlight.
A small rabbit cheers the CI flight! 🥕

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check	✅ Passed	The title succinctly summarizes the primary change by indicating the addition of E2E tests for the home page, header, and footer components, matching the content of the pull request.
Docstring Coverage	✅ Passed	No functions found in the changes. Docstring coverage check skipped.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (167fbb9) to head (b2aece8).
⚠️ Report is 1 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff            @@
##            master     #4194   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           22        22           
  Lines          780       780           
  Branches       144       144           
=========================================
  Hits           780       780           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[coderabbitai]

Actionable comments posted: 4

🧹 Nitpick comments (12)

.gitignore (1)

25-26: Remove duplicate entries.

These cypress ignore patterns are already defined at lines 17-18. The duplicate entries should be removed to maintain a clean .gitignore file.

Apply this diff to remove the duplicates:

-cypress/videos
-cypress/screenshots

cypress/support/commands.js (1)

1-37: Consider implementing actual commands or removing unused template.

This file contains only commented examples without any actual custom commands. Consider either:

1. Implementing specific custom commands needed for your E2E tests
2. Removing the file if no custom commands are required yet

Having template-only files can add clutter to the codebase.

cypress/pages/ToolsPage.js (1)

1-7: Consider expanding the page object with element interactions.

The basic page object structure is correct. However, for comprehensive E2E testing, consider adding:

• Element selectors for key page components
• Action methods for user interactions
• Helper methods for common assertions

This will make your tests more maintainable and reusable.

Example expansion:

class ToolsPage {
  visit() {
    cy.visit('/tools');
  }

  get toolsHeader() {
    return cy.get('[data-testid="tools-header"]');
  }

  verifyPageLoaded() {
    this.toolsHeader.should('be.visible');
    return this;
  }
}

cypress/pages/CommunityPage.js (1)

1-7: Page object structure is consistent and correct.

The implementation follows the same pattern as other page objects in the suite, which is good for consistency. Consider the same enhancements suggested for ToolsPage.js to make it more comprehensive for E2E testing.

cypress/pages/RoadmapPage.js (1)

1-7: LGTM! Consider enhancing with element interaction methods.

The page object follows the standard Cypress page object model pattern correctly. The implementation is clean and consistent.

Consider enhancing this page object with methods to interact with specific elements on the roadmap page:

class RoadmapPage {
  visit() {
    cy.visit('/roadmap');
  }
+
+  verifyPageTitle() {
+    cy.get('h1').should('contain', 'Vision & Roadmap');
+    return this;
+  }
+
+  verifyPageLoaded() {
+    cy.url().should('include', '/roadmap');
+    return this;
+  }
}

tsconfig.json (1)

31-31: Improve formatting for better readability.

The inclusion of Cypress files in the TypeScript configuration is correct and necessary for proper tooling support.

Consider improving the formatting for better readability:

-    "**/*.json"
-, "cypress/support/e2e.js", "cypress/support/commands.js", "cypress.config.js"  ],
+    "**/*.json",
+    "cypress/support/e2e.js",
+    "cypress/support/commands.js", 
+    "cypress.config.js"
+  ],

cypress/homepage.cy.js (1)

33-33: Fix missing semicolon.

  it('User verifies important links', () => {
    homePage.verifyHomepageCardLinks();
- })
+ });

cypress/footer.cy.js (3)

11-13: Consider consistent destructuring usage.

For consistency with the social links test, consider using destructuring here as well:

  it('User verifies the initiative section', () => {
-   footer.initiativeLinks.forEach((link) => {
-     footer.verifyLink(link.href, link.text);
+   footer.initiativeLinks.forEach(({ href, text }) => {
+     footer.verifyLink(href, text);
    });
  });

---

23-25: Apply consistent destructuring pattern.

For consistency with other tests, use destructuring here as well:

  it('User verifies the news section', () => {
-   footer.newsLinks.forEach((link) => {
-     footer.verifyLink(link.href, link.text);
+   footer.newsLinks.forEach(({ href, text }) => {
+     footer.verifyLink(href, text);
    });
  });

---

28-30: Clarify the empty text parameter for Netlify link test.

The empty string passed as the text parameter might indicate that the Netlify link doesn't have visible text or uses an image. Consider adding a comment to explain this or using a more descriptive approach.

  it('User verifies Netlify link', () => {
-   footer.verifyLink('https://netlify.com', '');
+   // Netlify link might be an image/logo without text
+   footer.verifyLink('https://netlify.com', '');
  });

cypress/pages/header.js (1)

6-11: Consider adding error handling for element not found.

The current implementation assumes the navigation item exists. Consider adding validation:

  verifyDropdownSections(navItemName) {
    cy.get(`[data-testid="Navbar-main"] a`)
      .contains(navItemName)
+     .should('exist')
      .trigger('mouseover');
    cy.get(`[data-testid="Flyout-main"]`).should('be.visible');
  }

cypress.config.js (1)

14-14: Consider environment-specific baseUrl configuration

The hardcoded baseUrl: 'http://127.0.0.1:3000' works for local development but consider making this configurable for different environments (CI/CD, staging, etc.) using environment variables.

-    baseUrl: 'http://127.0.0.1:3000',
+    baseUrl: process.env.CYPRESS_BASE_URL || 'http://127.0.0.1:3000',

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between d2a9a78 and c8471d8.

⛔ Files ignored due to path filters (1)

• package-lock.json is excluded by !**/package-lock.json

📒 Files selected for processing (19)

• .gitignore (1 hunks)
• cypress.config.js (1 hunks)
• cypress/fixtures/example.json (1 hunks)
• cypress/footer.cy.js (1 hunks)
• cypress/header.cy.js (1 hunks)
• cypress/homepage.cy.js (1 hunks)
• cypress/pages/BlogPage.js (1 hunks)
• cypress/pages/CaseStudiesPage.js (1 hunks)
• cypress/pages/CommunityPage.js (1 hunks)
• cypress/pages/DocsPage.js (1 hunks)
• cypress/pages/Footer.js (1 hunks)
• cypress/pages/RoadmapPage.js (1 hunks)
• cypress/pages/ToolsPage.js (1 hunks)
• cypress/pages/header.js (1 hunks)
• cypress/pages/homepage.js (1 hunks)
• cypress/support/commands.js (1 hunks)
• cypress/support/e2e.js (1 hunks)
• package.json (2 hunks)
• tsconfig.json (1 hunks)

🧰 Additional context used

🧬 Code Graph Analysis (2)

cypress/pages/RoadmapPage.js (1)

pages/roadmap.tsx (1)

• RoadmapPage (485-696)

cypress/pages/Footer.js (1)

components/footer/Footer.tsx (1)

• Footer (14-127)

⏰ Context from checks skipped due to timeout of 180000ms (5)

• GitHub Check: Redirect rules - asyncapi-website
• GitHub Check: Header rules - asyncapi-website
• GitHub Check: Pages changed - asyncapi-website
• GitHub Check: Test NodeJS PR - macos-13
• GitHub Check: Test NodeJS PR - windows-latest

🔇 Additional comments (12)

cypress/fixtures/example.json (1)

1-5: ```shell
#!/bin/bash

Search for any usage of the example fixture in the Cypress tests

1. Direct cy.fixture('example')

rg -n "cy.fixture(['"]example" cypress/ || echo "No direct cy.fixture('example') references found."

2. fixture: 'example' (used in intercept/route)

rg -n "fixture\s*:\s*['"]example" cypress/ || echo "No intercept/route fixture usage found."

3. import example.json

rg -n "import.*example.json" cypress/ || echo "No import of example.json found."

4. require example.json

rg -n "require.*example.json" cypress/ || echo "No require of example.json found."

</details>
<details>
<summary>cypress/pages/BlogPage.js (1)</summary>

`1-7`: **LGTM! Consistent page object implementation.**

The BlogPage class follows the same clean pattern as other page objects in the suite. The implementation is correct and maintains consistency across the testing framework.

</details>
<details>
<summary>cypress/pages/CaseStudiesPage.js (1)</summary>

`1-7`: **LGTM! Excellent consistency across page objects.**

The CaseStudiesPage maintains the same clean, consistent pattern as the other page objects in this PR. The implementation is correct and the structure is well-organized.

</details>
<details>
<summary>package.json (2)</summary>

`10-10`: **LGTM! Standard E2E test script addition.**

The test:e2e script is properly configured to run Cypress tests in headless mode, which is appropriate for CI/CD integration.

---

`152-152`: **Verify Cypress version for latest security updates.**

The Cypress dependency addition follows standard practices for E2E testing integration.




Please verify that Cypress version 14.4.0 is current and includes the latest security updates:

```web
What is the latest stable version of Cypress and are there any known security vulnerabilities in version 14.4.0?

cypress/support/e2e.js (2)

1-17: Standard Cypress support file implementation.

The file follows Cypress conventions with appropriate comments and import structure.

---

16-17: Verify that the commands.js file exists.

The import statement references './commands' which should correspond to a commands.js file in the same directory.

#!/bin/bash
# Description: Check if the commands.js file exists in the cypress/support directory
# Expected: File should exist and be properly structured

fd -t f "commands.js" cypress/support/

cypress/homepage.cy.js (1)

1-34: Well-structured test suite with clear test organization.

The test suite follows Cypress best practices with:

• Proper use of page object pattern
• Clear and descriptive test names
• Appropriate setup in beforeEach hook
• Good separation of concerns with individual test cases

cypress/footer.cy.js (1)

1-31: Well-organized footer validation test suite.

The test suite effectively validates different footer sections using a data-driven approach with forEach loops. Good use of the page object pattern.

cypress/pages/header.js (1)

1-26: Excellent page object implementation with good abstraction.

The class demonstrates several best practices:

• Clean abstraction with generic method and specific wrappers
• Proper use of data-testid selectors
• Appropriate mouseover trigger for dropdown testing
• Good method naming and structure

cypress/pages/Footer.js (1)

1-44: LGTM - Well-structured page object implementation

The Footer page object follows Cypress best practices with clean separation of concerns, reusable verification methods, and well-organized link data structures. The verifyLink method properly handles both text and attribute validation.

cypress/pages/homepage.js (1)

119-147: LGTM - Clean navigation methods

The navigation methods follow good practices by returning page object instances for method chaining, enabling fluent test writing.

[anushkaaaaaaaa]

recording of e2e tests for homepage, header and footer

homepage.cy.js.Index.homepage.cy.js.-.asyncapi.-.Visual.Studio.Code.2025-06-19.22-15-28.mp4

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (3)

cypress/pages/BaseFooterPage.js (3)

2-4: Accept a path argument in visit() (default '/')

This makes the base page reusable beyond the homepage with zero call‑site changes.

-  visit() {
-    cy.visit('/');
-  }
+  visit(path = '/') {
+    cy.visit(path);
+  }

---

6-12: Make text assertion explicit and guard against ambiguous matches

• Prefer 'contain.text' for clarity over generic 'contain'.
• If the same href appears in both header and footer, ensure calls are scoped via cy.within(...) in the caller to avoid multi‑element subjects.

-    return text ? chain.and('contain', text) : chain;
+    return text ? chain.and('contain.text', text) : chain;

Please confirm Footer.js wraps calls with footer scoping (e.g., cy.get('footer').within(...)).

---

1-1: Align class name with filename for clarity

Either rename the file to BasePage.js or adjust the class/export to match the filename.

-class BasePage {
+class BaseFooterPage {
@@
-export default BasePage;
+export default BaseFooterPage;

Also applies to: 15-15

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between c566fad and 5adf360.

📒 Files selected for processing (1)

• cypress/pages/BaseFooterPage.js (1 hunks)

🔇 Additional comments (1)

cypress/pages/BaseFooterPage.js (1)

1-15: LGTM: concise, reusable base utilities

Simple, readable base with sensible defaults and Cypress chaining preserved.

[coderabbitai]

Actionable comments posted: 0

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

components/tools/ToolsCard.tsx (1)

203-207: Add noopener to external links opened in a new tab

For security (tabnabbing), include noopener alongside noreferrer on target='_blank' links.

Apply this diff:

-                  rel='noreferrer'
+                  rel='noopener noreferrer'
@@
-                  rel='noreferrer'
+                  rel='noopener noreferrer'
@@
-                rel='noreferrer'
+                rel='noopener noreferrer'
@@
-                rel='noreferrer'
+                rel='noopener noreferrer'

Also applies to: 219-223, 233-237, 251-255

🧹 Nitpick comments (6)

components/tools/ToolsCard.tsx (3)

67-71: Avoid stale state in delayed hover handlers

setTimeout closures capture a stale visible; use functional updates to avoid race conditions.

Apply this diff:

-              onMouseEnter={() =>
-                setTimeout(() => {
-                  if (!visible.desc) setVisible({ ...visible, desc: true });
-                }, 400)
-              }
+              onMouseEnter={() =>
+                setTimeout(() => {
+                  setVisible((prev) => (prev.desc ? prev : { ...prev, desc: true }));
+                }, 400)
+              }
@@
-                onMouseLeave={() =>
-                  setTimeout(() => {
-                    if (visible.desc) setVisible({ ...visible, desc: false });
-                  }, 300)
-                }
+                onMouseLeave={() =>
+                  setTimeout(() => {
+                    setVisible((prev) => (prev.desc ? { ...prev, desc: false } : prev));
+                  }, 300)
+                }

Also applies to: 75-79

---

34-41: Recompute truncation on resize/content change

useEffect([]) runs once; truncation can change with layout/resize. Observe the element size instead.

Apply this diff:

-  useEffect(() => {
-    if (descriptionRef.current) {
-      setIsTruncated(
-        descriptionRef.current?.scrollHeight! >
-          descriptionRef.current?.clientHeight!
-      );
-    }
-  }, []);
+  useEffect(() => {
+    const el = descriptionRef.current;
+    if (!el) return;
+    const compute = () => setIsTruncated(el.scrollHeight > el.clientHeight);
+    compute();
+    const ro = new ResizeObserver(compute);
+    ro.observe(el);
+    return () => ro.disconnect();
+  }, []);

---

146-151: Use stable keys instead of array index

Prefer item.name as the key to avoid reconciliation issues.

Apply this diff:

-                      <Tag
-                        key={index}
+                      <Tag
+                        key={item.name}
                         name={item.name}
                         bgColor={item.color}
                         borderColor={item.borderColor}
                       />
@@
-                      <Tag
-                        key={index}
+                      <Tag
+                        key={item.name}
                         name={item.name}
                         bgColor={item.color}
                         borderColor={item.borderColor}
                       />

Also applies to: 173-178

components/tools/ToolsDashboard.tsx (3)

30-33: Remove LegacyRef casts by typing refs correctly

Initialize refs with null and pass them directly. Also guard with optional chaining where accessed.

Apply this diff:

-  const filterRef = useRef<HTMLDivElement>(); // used to provide ref to the Filter menu and outside click close feature
+  const filterRef = useRef<HTMLDivElement | null>(null); // used to provide ref to the Filter menu and outside click close feature
   // used to provide ref to the Category menu and outside click close feature
-  const categoryRef = useRef<HTMLDivElement>();
+  const categoryRef = useRef<HTMLDivElement | null>(null);
@@
-      if (
-        openFilter &&
-        filterRef.current &&
-        !filterRef.current.contains(event.target as Node)
-      ) {
+      if (openFilter && filterRef.current && !filterRef.current.contains(event.target as Node)) {
         setOpenFilter(false);
       }
@@
-      if (
-        openCategory &&
-        categoryRef.current &&
-        !categoryRef.current.contains(event.target as Node)
-      ) {
+      if (openCategory && categoryRef.current && !categoryRef.current.contains(event.target as Node)) {
         setopenCategory(false);
       }
@@
-            <div
-              className='relative h-auto w-full'
-              ref={filterRef as React.LegacyRef<HTMLDivElement>}
-            >
+            <div className='relative h-auto w/full' ref={filterRef}>
@@
-            <div
-              className='relative h-auto w/full'
-              ref={categoryRef as React.LegacyRef<HTMLDivElement>}
-            >
+            <div className='relative h-auto w/full' ref={categoryRef}>

Also applies to: 225-228, 245-248, 45-49, 65-68

---

100-105: Avoid setState inside useMemo and derive flags instead

setCheckToolsList is set within useMemo; side-effects inside useMemo are an anti-pattern. Derive a hasAny boolean from the computed list or move the update to a useEffect that depends on toolsList.

I can provide a refactor to return { toolsList, hasAny } from the memo and remove setCheckToolsList; want me to draft it?

Also applies to: 170-173, 212-218

---

290-296: Make “Clear Filters” a real button for a11y

It’s interactive; use a button with type='button' and aria-label.

-          <div
-            className='mt-4 flex cursor-pointer items-center text-gray-600 hover:text-black'
-            onClick={clearFilters}
-          >
+          <button
+            type='button'
+            className='mt-4 flex items-center text-gray-600 hover:text-black'
+            onClick={clearFilters}
+            aria-label='Clear filters'
+          >
             <Cross />
             <span className='ml-3'>Clear Filters</span>
-          </div>
+          </button>

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 5adf360 and dcbcdd6.

📒 Files selected for processing (4)

• components/footer/FooterData.ts (1 hunks)
• components/tools/ToolsCard.tsx (12 hunks)
• components/tools/ToolsDashboard.tsx (13 hunks)
• cypress/footer.cy.js (1 hunks)

🧰 Additional context used

🧠 Learnings (1)

📚 Learning: 2024-11-01T12:48:22.034Z

Learnt from: akshatnema
PR: asyncapi/website#3136
File: tests/fixtures/tools/automated-tools.json:8-9
Timestamp: 2024-11-01T12:48:22.034Z
Learning: In the `tests/fixtures/tools/automated-tools.json` file, the `language` field within the `filters` object can be either a string or an array. Both formats are acceptable and supported in the codebase.

Applied to files:

• components/tools/ToolsDashboard.tsx

🧬 Code graph analysis (3)

cypress/footer.cy.js (2)

components/footer/Footer.tsx (1)

• Footer (14-127)

components/footer/FooterData.ts (4)

• initiativeLinks (19-40)
• socialMediaData (42-67)
• newsLinks (69-74)
• footerMiscData (76-78)

components/tools/ToolsCard.tsx (1)

components/typography/Heading.tsx (1)

• Heading (30-85)

components/tools/ToolsDashboard.tsx (1)

context/ToolFilterContext.tsx (1)

• ToolFilterContext (12-18)

🪛 GitHub Actions: PR testing - if Node project

components/tools/ToolsCard.tsx

[error] 3-3: Prettier formatting issue detected in ToolsCard.tsx.

---

[error] 36-36: Prettier formatting issue detected in ToolsCard.tsx.

---

[error] 62-62: Prettier formatting issue detected in ToolsCard.tsx.

---

[error] 81-81: Prettier formatting issue detected in ToolsCard.tsx.

---

[error] 86-86: Prettier formatting issue detected in ToolsCard.tsx.

---

[error] 146-146: Prettier formatting issue detected in ToolsCard.tsx.

---

[error] 161-161: Prettier formatting issue detected in ToolsCard.tsx.

---

[error] 173-173: Prettier formatting issue detected in ToolsCard.tsx.

---

[error] 193-193: Prettier formatting issue detected in ToolsCard.tsx.

---

[error] 209-209: Prettier formatting issue detected in ToolsCard.tsx.

---

[error] 225-225: Prettier formatting issue detected in ToolsCard.tsx.

---

[error] 240-240: Prettier formatting issue detected in ToolsCard.tsx.

---

[error] 258-258: Prettier formatting issue detected in ToolsCard.tsx.

---

[error] 258-258: Prettier formatting issue detected in ToolsCard.tsx.

components/tools/ToolsDashboard.tsx

[error] 2-2: Prettier formatting issue detected in ToolsDashboard.tsx.

🔇 Additional comments (6)

components/tools/ToolsCard.tsx (1)

3-6: Fix Prettier violations to unblock CI

CI flags multiple Prettier issues on this file. Please run the formatter (e.g., pnpm lint --fix or npx prettier --write) to resolve them.

Also applies to: 36-41, 62-64, 81-83, 86-89, 146-151, 161-163, 173-178, 193-196, 209-213, 225-227, 240-244, 258-262

components/tools/ToolsDashboard.tsx (1)

2-9: Fix Prettier violation

Format the multiline React import to satisfy Prettier.

cypress/footer.cy.js (2)

1-7: Good: imports use correct casing/path

The FooterData import matches filesystem casing, avoiding Linux CI resolution issues.

---

16-37: Solid, data-driven footer link checks

Iterating over shared FooterData keeps tests in sync with site data. Nice use of a page object to scope to the footer.

components/footer/FooterData.ts (2)

76-86: LGTM: shared footer data module

Centralizing link data with typed exports is clean and test-friendly.

---

29-31: Fix broken “Brand” link (404)

This URL 404s. Point to a stable path (repo root) to avoid broken footer links.

Apply this diff:

-    url: 'https://github.com/asyncapi/brand/blob/master/brand-guidelines/README.md'
+    url: 'https://github.com/asyncapi/brand'

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

cypress/footer.cy.js (1)

11-27: Good use of source data to avoid duplication.

These tests correctly import data from the source (FooterData.ts) rather than duplicating it in fixtures, addressing the feedback from PR reviewers about avoiding double maintenance.

Consider adding an assertion to verify the total count of links in each section matches expectations, ensuring no unexpected links are rendered:

it('verifies the initiative links in the footer', () => {
  cy.get('[data-testid="Footer-initiative-links"]').should('have.length', initiativeLinks.length);
  initiativeLinks.forEach(({ url, label }) => {
    footer.verifyFooterLink(url, label);
  });
});

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between dcbcdd6 and 75ac772.

📒 Files selected for processing (3)

• components/tools/ToolsCard.tsx (1 hunks)
• components/tools/ToolsDashboard.tsx (3 hunks)
• cypress/footer.cy.js (1 hunks)

🚧 Files skipped from review as they are similar to previous changes (2)

• components/tools/ToolsCard.tsx
• components/tools/ToolsDashboard.tsx

🧰 Additional context used

🧬 Code graph analysis (1)

cypress/footer.cy.js (2)

components/footer/Footer.tsx (1)

• Footer (14-127)

components/footer/FooterData.ts (4)

• initiativeLinks (19-40)
• socialMediaData (42-67)
• newsLinks (69-74)
• footerMiscData (76-78)

🔇 Additional comments (2)

cypress/footer.cy.js (2)

4-9: LGTM - Test setup follows Cypress best practices.

The test suite setup correctly uses the Page Object Model pattern with a beforeEach hook to ensure each test starts with a clean page visit.

---

29-31: Verify the Netlify link test validates the image badge correctly.

The test passes an empty string for the label parameter, which differs from other tests. Since the Netlify link renders as an image badge (see Footer.tsx lines 113-120) rather than text, confirm that:

1. verifyFooterLink with an empty label correctly validates the image link
2. The alt text ('Deploys by Netlify') or other accessibility attributes are validated

If verifyFooterLink doesn't handle image links appropriately, consider adding a dedicated test or updating the method to validate the image's presence and alt text:

it('verifies the Netlify badge in the footer', () => {
  cy.get('a[href="https://netlify.com"]')
    .should('exist')
    .find('img[alt="Deploys by Netlify"]')
    .should('be.visible');
});

[coderabbitai]

Actionable comments posted: 0

♻️ Duplicate comments (1)

components/footer/FooterData.ts (1)

29-31: Broken Brand link (duplicate issue).

This link was already flagged in a previous review as returning 404 because brand-guidelines/README.md does not exist on the master branch.

🧹 Nitpick comments (1)

components/footer/FooterData.ts (1)

4-17: Consolidate duplicate interfaces.

FooterLink, SocialMediaData, and NewsLink are structurally identical (both have url and label fields). Consolidating them into a single interface reduces duplication and simplifies maintenance.

Apply this diff to consolidate:

-export interface FooterLink {
+export interface LinkData {
   url: string;
   label: string;
 }

-export interface SocialMediaData {
-  url: string;
-  label: string;
-}
-
-export interface NewsLink {
-  url: string;
-  label: string;
-}

Then update the type annotations:

-export const initiativeLinks: FooterLink[] = [
+export const initiativeLinks: LinkData[] = [

-export const socialMediaData: SocialMediaData[] = [
+export const socialMediaData: LinkData[] = [

-export const newsLinks: NewsLink[] = [
+export const newsLinks: LinkData[] = [

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between e0e7680 and bd2458a.

📒 Files selected for processing (1)

• components/footer/FooterData.ts (1 hunks)

⏰ Context from checks skipped due to timeout of 180000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: Test NodeJS PR - windows-latest

🔇 Additional comments (1)

components/footer/FooterData.ts (1)

1-3: LGTM! Clean data structure and centralization.

The centralized approach eliminates the duplicate maintenance concern raised in the PR comments. The data arrays are well-organized, links are properly formatted, and the composite export using the spread operator correctly flattens the misc data properties into the top-level object.

Also applies to: 19-28, 32-74, 76-85