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

Consider a new, informative page in Chai's documentation for working with Errors #1405

Open
jojenki opened this issue Jun 25, 2021 · 1 comment

Comments

@jojenki
Copy link

jojenki commented Jun 25, 2021

Simple working example:

class UntypedError {
  private readonly message;
  constructor(message: string) {
    this.message = message;
  }
}

class TypedError extends Error {
  constructor(message: string) {
    super(message);
  }
}

describe("Error Experimentation", () => {
  it("should pass in all of these cases", () => {
    // Pass
    expect(new UntypedError("untyped error no array")).to.deep.equal(new UntypedError("untyped error no array"));
    // Fail - This is the unexpected part, to me.
    expect(new TypedError("typed error no array")).to.deep.equal(new TypedError("typed error no array"));

    // This is closer to what I'm actually trying to test but is fundamentally the same thing.
    // Pass
    expect([new UntypedError("untyped error array")]).to.deep.include(new UntypedError("untyped error array"));
    // Fail - The fact that it's part of an array is probably irrelevant, but I cannot be certain.
    expect([new TypedError("typed error array")]).to.deep.include(new TypedError("typed error array"));
  });
});

I've been working on this for a couple of days now and have seen some resources / hints regarding Chai basically making the decision that two Errors with different call-stacks are evaluated as different, even if they are the same type and have the same message. So, I think that's what's going on here.

My ask is that the team create some dedicated documentation that explains this (so I can be certain that that's what is actually going on here) and propose some alternatives or provide a rationale on why this type of testing shouldn't work / shouldn't be done.

And, if such documentation does already exist, I apologize for wasting your time, and my feedback would be that, that documentation is hard to find. :)

@koddsson
Copy link
Member

koddsson commented Oct 4, 2021

Hey @jojenki; Error equality is something that seems to be not implemented in chai right now due to some issues that are listed in #1065. Depending on your situation, you might want to assert on the error properties such as name and message rather than asserting the equality of the error objects themselves.

For the question of documentation, I'm not quite sure what would be the best thing to do. Where did you look for information on this? Maybe we can make a PR to the documentation that you were looking at to add this piece of information.

undergroundwires added a commit to undergroundwires/privacy.sexy that referenced this issue Mar 11, 2022
- Use better error messages with more context.
- Unify their validation logic and share tests.
- Validate also type of the name.
- Refactor node (Script/Category) parser tests for easier future
  changes and cleaner test code (using `TestBuilder` to do dirty work in
  unified way).
- Add more tests. Custom `Error` properties are compared manually due to
  `chai` not supporting deep equality checks (chaijs/chai#1065,
  chaijs/chai#1405).
LarrMarburger pushed a commit to LarrMarburger/privacy.sexy that referenced this issue Nov 16, 2023
- Use better error messages with more context.
- Unify their validation logic and share tests.
- Validate also type of the name.
- Refactor node (Script/Category) parser tests for easier future
  changes and cleaner test code (using `TestBuilder` to do dirty work in
  unified way).
- Add more tests. Custom `Error` properties are compared manually due to
  `chai` not supporting deep equality checks (chaijs/chai#1065,
  chaijs/chai#1405).
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

No branches or pull requests

2 participants