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

Testing @error in mixins #121

Closed
benkyriakou opened this issue Feb 25, 2018 · 3 comments

Comments

@benkyriakou
Copy link

commented Feb 25, 2018

I have a question on testing errors raised by mixins, since this doesn't appear to be covered as a standard use case. Taking inspiration from the Susy approach I've written some mixin tests that use a similar approach, but using a second mixin rather than a function since I don't believe it's possible to return a meaningful value using the exact same method. This results in code similar to:

$_is-test: false !default;

@mixin _error($error, $override: $_is-test) {
  @if $override {
    error: $error;
  }
  @else {
    @error $error;
  }
}

@mixin my-mixin {
  ...

  @if $error-condition {
    @include _error('Error message);
  }
}

With an accompanying test like:

@import 'true';

$_is-test: true;

@include describe('An example test') {
  @include it('Tests an error is raised when I do something bad') {
    @include assert {
      @include output {
        @include my-mixin;
      }
      
      @include expect {
        error: "Error message";
      }
    };
  };
}

I'm very much a SASS novice, and this seems a bit clunky, so any pointers on whether there's a better way to go about achieving this would be great. I'd definitely be in favour of having some kind of explicit way of handing errors built in, since this has required some fudging of the original mixin to achieve a logical flow that won't accidentally raise other errors and break the tests.

@mirisuzanne

This comment has been minimized.

Copy link
Member

commented Feb 26, 2018

That seems like a reasonable approach, and should work for testing mixin errors. But the disadvantage with using mixins/css-output (also not very meaningful in my mind) is that you can never call it from inside a function. If you ever want to test a function error, you'll have to re-write this as a function anyway – since functions cannot call mixins. I'm not convinced that an abstract sense of "meaningful value returns" is a good reason to lose that functionality. In the case of an error, returning that an error has occurred seems pretty meaningful to me. :)

@benkyriakou

This comment has been minimized.

Copy link
Author

commented Feb 28, 2018

Thanks for the reply! I may have been confusing the matter by calling it a 'meaningful' value - I can see that if I wanted to use this for testing functions I would need to convert it to something like:

$_is-test: false !default;

@function _error($error, $override: $_is-test) {
  @if $override {
    @return $error;
  }
  @else {
    @error $error;
  }
}

But I don't believe it's possible to use this function to return anything from a mixin, since mixins have to return something CSS-like.

I suppose my actual question is: am I approaching this problem correctly. The code this is being used to test is this grid-generating mixin. Of the available options:

  1. Make this a function instead, and test it using the _error() function
  2. Write this as a mixin and test it using the _error() mixin
  3. Write this as a mixin an test it using the _error() function
  4. Option D

I can't see that 3. is possible in SASS, and 1. doesn't seem to be a feasible way to generate the required grid CSS. I feel like I'm being obtuse and missing hidden Option D, but I'm probably over-thinking it!

@mirisuzanne

This comment has been minimized.

Copy link
Member

commented Feb 28, 2018

Yes, everything here looks reasonable to me. You are approaching this problem as correctly as anyone! :)

The way that I handle use-case 3 is by breaking all the mixin logic out into functions, and unit-testing the error at that level, rather than the mixin level. I think either solution is fine. ¯\_(ツ)_/¯

@mirisuzanne mirisuzanne closed this Mar 6, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.