Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Test/expand tests #389

Open
wants to merge 8 commits into
base: main
Choose a base branch
from
Open

Test/expand tests #389

wants to merge 8 commits into from

Conversation

SalihuDickson
Copy link
Contributor

@SalihuDickson SalihuDickson commented Nov 25, 2024

Description

This PR aims to simplify and expand tests for the ecc-utils design form, it also sets a standard for how the other tests for how tests for the other components will be written.

Summary by Sourcery

Expand and refactor tests for the ecc-utils design form to cover a wider range of input types and field options, and improve test component modularity.

Enhancements:

  • Refactor test components to improve modularity and reusability by introducing new classes for different field types.

Tests:

  • Expand and simplify tests for the ecc-utils design form, covering various input types, field options, and form behaviors.

Chores:

  • Add @types/mocha as a new development dependency in package.json.

Copy link

changeset-bot bot commented Nov 25, 2024

⚠️ No Changeset found

Latest commit: e1c4487

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

Copy link

vercel bot commented Nov 25, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
elixir-cloud-components ✅ Ready (Inspect) Visit Preview 💬 Add feedback Nov 25, 2024 2:30pm

Copy link
Contributor

sourcery-ai bot commented Nov 25, 2024

Reviewer's Guide by Sourcery

This PR significantly refactors and expands the test suite for the ecc-utils-design form component. The changes focus on improving test organization, readability, and maintainability by introducing a new test structure and helper classes for handling different form field types.

Class diagram for EccUtilsDesignForm changes

classDiagram
    class EccUtilsDesignForm {
        +handleTusFileUpload(e: Event, field: Field): Promise<Record<string, string> | null>
        +renderInputTemplate(field: Field, path: string): TemplateResult
        +renderArrayTemplate(field: Field, path: string): TemplateResult
        +renderGroupTemplate(field: Field, path: string): TemplateResult
        +renderErrorTemplate(): TemplateResult
        +renderSuccessTemplate(): TemplateResult
    }
Loading

File-Level Changes

Change Details Files
Introduced new test helper classes for form field interactions
  • Created base Field class with common element interaction methods
  • Added specialized classes for Input, Select, and Button elements
  • Implemented type-specific methods like fill(), toggle(), and select()
  • Added support for both LitElement and standard DOM elements
packages/ecc-utils-design/src/internal/TestComponent.ts
Restructured test organization by form field type
  • Separated tests into logical sections by field type (input, select, file, etc.)
  • Added comprehensive tests for each field type's rendering and functionality
  • Improved test descriptions for better clarity
  • Added new test cases for field options and validation
packages/ecc-utils-design/src/components/form/tests/form.test.ts
Enhanced form component data handling and validation
  • Improved form data handling for empty fields
  • Added better support for field validation
  • Updated file upload handling with better error management
  • Enhanced form submission data processing
packages/ecc-utils-design/src/components/form/form.ts
Simplified test data and improved test identifiers
  • Removed complex test data structures in favor of simpler, focused examples
  • Updated data-testid attributes for better clarity
  • Removed redundant test IDs constant object
packages/ecc-utils-design/src/components/form/tests/testData.ts
packages/ecc-utils-design/src/components/form/tests/form.class.ts

Tips and commands

Interacting with Sourcery

  • Trigger a new review: Comment @sourcery-ai review on the pull request.
  • Continue discussions: Reply directly to Sourcery's review comments.
  • Generate a GitHub issue from a review comment: Ask Sourcery to create an
    issue from a review comment by replying to it.
  • Generate a pull request title: Write @sourcery-ai anywhere in the pull
    request title to generate a title at any time.
  • Generate a pull request summary: Write @sourcery-ai summary anywhere in
    the pull request body to generate a PR summary at any time. You can also use
    this command to specify where the summary should be inserted.

Customizing Your Experience

Access your dashboard to:

  • Enable or disable review features such as the Sourcery-generated pull request
    summary, the reviewer's guide, and others.
  • Change the review language.
  • Add, remove or edit custom review instructions.
  • Adjust other review settings.

Getting Help

Copy link
Contributor

@sourcery-ai sourcery-ai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @SalihuDickson - I've reviewed your changes and they look great!

Here's what I looked at during the review
  • 🟡 General issues: 3 issues found
  • 🟢 Security: all looks good
  • 🟢 Testing: all looks good
  • 🟡 Complexity: 1 issue found
  • 🟢 Documentation: all looks good

Sourcery is free for open source - if you like our reviews please consider sharing them ✨
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.

const file = (e.target as HTMLInputElement).files?.[0];

if (!file) {
console.error("No file selected for upload.");
return;
return null;
}

try {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

issue: File upload error handling needs improvement

The handleTusFileUpload method silently fails and returns null on error. Consider adding proper error state handling and user feedback through the form's error display mechanism.

text = "test value"
) {
public async fill(text = "test value") {
if (this.el.getAttribute("disable")) return;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

issue: Use standard 'disabled' attribute instead of custom 'disable'

The code uses a non-standard 'disable' attribute. Use the standard HTML 'disabled' attribute instead for better compatibility and consistency.

} else {
_.set(this.form, path, value);
_.set(this.form, path, value.trim());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggestion (performance): Unnecessary string trimming on every input change

Trimming the input value on every change is inefficient. Consider moving the trim operation to the blur event handler or form submission instead.

Suggested change
_.set(this.form, path, value.trim());
_.set(this.form, path, value);
this.addEventListener('blur', () => {
_.set(this.form, path, value.trim());
}, { once: true });

component: ComponentType;
constructor(component: ComponentType) {
this.component = component;
export default class Field {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

issue (complexity): Consider consolidating the class hierarchy into a single class with utility functions for better code organization

The inheritance hierarchy adds unnecessary complexity. Consider simplifying to a single class using utility functions:

export class TestComponent {
  private el: ParentElement;
  private component: ComponentType;

  constructor(el: Element | LitElement, instance: InstanceType = "element") {
    if (instance === "litElement") {
      this.component = el as LitElement;
      this.el = el.shadowRoot!;
    } else {
      this.el = el;
    }
  }

  private getElement(label?: string, testId?: string, all = false) {
    // Existing _getFields logic
  }

  // Utility functions instead of inheritance
  private async handleElementAction(el: HTMLElement, action: () => void) {
    if (el.getAttribute("disable")) return;
    action();
    await this.component?.updateComplete;
  }

  public async fillInput(el: HTMLInputElement, text = "test value") {
    return this.handleElementAction(el, () => {
      el.value = text;
      el.dispatchEvent(new Event("sl-input"));
    });
  }

  public async selectOption(el: HTMLSelectElement, label: string | number) {
    return this.handleElementAction(el, () => {
      // Existing select logic
    });
  }
}

This approach:

  1. Eliminates duplicate disable/update checks
  2. Removes unnecessary inheritance
  3. Keeps all functionality through focused utility functions
  4. Improves maintainability by centralizing common logic

?multiple=${field.fieldOptions?.multiple}
?required=${field.fieldOptions?.required}
@change=${async (e: Event) => {
if (!field.fileOptions?.tusOptions?.endpoint) return;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggestion (code-quality): Use block braces for ifs, whiles, etc. (use-braces)

Suggested change
if (!field.fileOptions?.tusOptions?.endpoint) return;
if (!field.fileOptions?.tusOptions?.endpoint) {


ExplanationIt is recommended to always use braces and create explicit statement blocks.

Using the allowed syntax to just write a single statement can lead to very confusing
situations, especially where subsequently a developer might add another statement
while forgetting to add the braces (meaning that this wouldn't be included in the condition).

if (inputField.type !== "file") {
throw new Error("inputField is not a valid file element");
public async upload(dataText = "test value") {
if (this.el.getAttribute("disable")) return;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggestion (code-quality): Use block braces for ifs, whiles, etc. (use-braces)

Suggested change
if (this.el.getAttribute("disable")) return;
if (this.el.getAttribute("disable")) {


ExplanationIt is recommended to always use braces and create explicit statement blocks.

Using the allowed syntax to just write a single statement can lead to very confusing
situations, especially where subsequently a developer might add another statement
while forgetting to add the braces (meaning that this wouldn't be included in the condition).

switchField.click();
await this.component.updateComplete;
public async toggle() {
if (this.el.getAttribute("disable")) return;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggestion (code-quality): Use block braces for ifs, whiles, etc. (use-braces)

Suggested change
if (this.el.getAttribute("disable")) return;
if (this.el.getAttribute("disable")) {


ExplanationIt is recommended to always use braces and create explicit statement blocks.

Using the allowed syntax to just write a single statement can lead to very confusing
situations, especially where subsequently a developer might add another statement
while forgetting to add the braces (meaning that this wouldn't be included in the condition).

numberOfClicks = 1
) => {
public select = async (label: number | string) => {
if (this.el.getAttribute("disable")) return;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggestion (code-quality): Use block braces for ifs, whiles, etc. (use-braces)

Suggested change
if (this.el.getAttribute("disable")) return;
if (this.el.getAttribute("disable")) {


ExplanationIt is recommended to always use braces and create explicit statement blocks.

Using the allowed syntax to just write a single statement can lead to very confusing
situations, especially where subsequently a developer might add another statement
while forgetting to add the braces (meaning that this wouldn't be included in the condition).

}

public click = async (numberOfClicks = 1) => {
if (this.el.getAttribute("disable")) return;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggestion (code-quality): Use block braces for ifs, whiles, etc. (use-braces)

Suggested change
if (this.el.getAttribute("disable")) return;
if (this.el.getAttribute("disable")) {


ExplanationIt is recommended to always use braces and create explicit statement blocks.

Using the allowed syntax to just write a single statement can lead to very confusing
situations, especially where subsequently a developer might add another statement
while forgetting to add the braces (meaning that this wouldn't be included in the condition).

}

export const elementIsVisible = (element: HTMLElement) => {
if (!element) return false;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggestion (code-quality): Use block braces for ifs, whiles, etc. (use-braces)

Suggested change
if (!element) return false;
if (!element) {


ExplanationIt is recommended to always use braces and create explicit statement blocks.

Using the allowed syntax to just write a single statement can lead to very confusing
situations, especially where subsequently a developer might add another statement
while forgetting to add the braces (meaning that this wouldn't be included in the condition).

@SalihuDickson
Copy link
Contributor Author

hey @anuragxxd, have you had a chance to take a look at this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant