Add a style guide for writing new specs #1363
Conversation
I've tried to capture the best practices I've come up with while writing tests in the HRX format, mixed with best practices from other testing traditions and a few rules that mostly serve to just establish a consistent style.
|
|
||
| [implementation-specific expectations]: README.md#implementation-specific-expectations | ||
|
|
||
| ### DO use Dart Sass's output as the default |
There was a problem hiding this comment.
Does this also apply to errors? Currently, dart-sass errors are sometimes inferior to ruby and libsass, e.g.:
libsass and ruby:
Invalid CSS after "... (foo: bar) or ": expected @supports condition (e.g. (display: flexbox)), was "{"
dart-sass:
expected "("
There was a problem hiding this comment.
Yes. This isn't about saying which errors are best, it's just about being consistent in formatting. If any implementation's errors need improvement, that's something that should be handled on that implementation's issue tracker, not by swapping output positions in the specs.
There was a problem hiding this comment.
If error is not what we want the canonical error message to look like, but is merely the current error message of dart-sass, perhaps all errors should be language-specific?
I.e. no error, only error-dart-sass and error-libsass.
There was a problem hiding this comment.
I think that could be a reasonable approach. Let's discuss it on a separate issue, though; until the infrastructure supports it, I'd like to keep this as the recommended approach.
I've tried to capture the best practices I've come up with while
writing tests in the HRX format, mixed with best practices from other
testing traditions and a few rules that mostly serve to just establish
a consistent style.