sass导入sass

sass导入sass

Lately, I have spent a decent amount of time working with Eduardo Bouças on include-media. We went through a lot of refactoring so decided to write some tests and run them on every commit to be sure we did not break anything. I’ll go through the details in this article.

最近，我在EduardoBouças的include-media上花费了大量时间。 我们经历了很多重构，因此决定编写一些测试并在每次提交时运行它们，以确保我们没有破坏任何东西。 我将在本文中详细介绍。

If you don’t know include-media yet, it is a very lightweight yet powerful breakpoint manager in Sass.

如果您还不知道include-media，它是Sass中一个非常轻量级但功能强大的断点管理器。

The provided public API is a single mixin, media(..) (hence the name of the library), but the whole thing is well thought enough so you can actually do wonders with it. A short example before getting started:

提供的公共API是单个mixin，即media(..) (因此具有库的名称)，但是整个过程都经过深思熟虑，因此您可以使用它进行实际操作。 开始之前的简短示例：

.my-component { width: 100%; // On screens larger or equal to *small* breakpoint, // make the component floated and half the size @include media('≥small') { float: left; width: 50%; } }

Now that’s pretty rad, isn’t it?

现在很漂亮，不是吗？

Anyway, so we came up with a little testing system that I would like to share with you guys. Of course, if you want to test a full framework, you might want to use True from Eric Suzanne instead, which is a full blown testing framework written in Sass, for Sass and was introduced and explained by David in a recent article on SitePoint.

无论如何，所以我们想出了一个小测试系统，希望与大家分享。 当然，如果您想测试一个完整的框架，则可能要改用Eric Suzanne的True ，它是Sass编写的一个完整的测试框架，适用于Sass，由David在SitePoint的最新文章中进行介绍和解释。

有什么想法 (What’s the idea?)

We wanted to run a few tests on the main private functions from the library any time we commit to the repository. If any test fails, the commit is aborted and the code needs to be fixed to allow the commit to pass. This way, we make sure that we can safely work on the library without risking breaking it (which is usually a bad thing).

每当我们提交到存储库时，我们都希望对库中的主要私有函数运行一些测试。 如果任何测试失败，则提交将被中止，并且需要修复代码以允许提交通过。 这样，我们确保可以安全地在库上工作而不会冒险破坏它(这通常是一件坏事)。

Achieving something like this ended up being surprisingly easy: we set up a pre-commit Git hook to run tests in both LibSass and Ruby Sass before any commiting. If the test is failing, we kill the process.

实现这样的事情最终变得非常容易：我们设置了一个预提交的 Git钩子，以便在提交之前在LibSass和Ruby Sass中运行测试。 如果测试失败，我们将终止该过程。

There are different ways to run Sass and LibSass. You can either have binaries, or you could use a wrapper. In our case, we opted for a tiny Gulp workflow, making it easy for us to run both Ruby Sass and LibSass.

有多种方法可以运行Sass和LibSass。 您可以具有二进制文件，也可以使用包装器。 在我们的案例中，我们选择了一个很小的Gulp工作流程，这使我们可以轻松地同时运行Ruby Sass和LibSass。

We wanted something very simple, so tests are written in Sass using SassyTester, which I introduced recently in the article Testing a Sass function in 5 minutes. SassyTester is about 25 lines long. The testing function only outputs a Sass map with the results from the tests. From there, we can do anything we want with it. In our case, we want to throw an error if a test fails. To do so, we have the @error directive from Sass!

我们想要非常简单的东西，所以测试是使用SassyTester用Sass 编写的 ，我最近在文章5分钟内测试Sass函数中介绍了它。 SassyTester大约25行。 测试功能仅输出Sass映射以及测试结果。 从那里，我们可以用它做任何我们想做的事情。 在我们的例子中，如果测试失败，我们想抛出一个错误。 为此，我们有来自Sass的@error指令！

When compiling the Sass tests, if the Gulp task encounters a Sass error, it exits the process while throwing an error itself, which bubbles up to the pre-commit hook and finally aborts the commit.

编译Sass测试时，如果Gulp任务遇到Sass错误，它将退出该进程，同时抛出错误，该错误会冒泡到预提交钩子，最后中止提交。

If we sum this up, it goes like this:

如果我们总结一下，它是这样的：

A pre-commit hook runs a test Gulp task on commit

预提交钩子在提交时运行test Gulp任务

The test Gulp task compiles Sass tests in both LibSass and Ruby Sass

test Gulp任务在LibSass和Ruby Sass中都编译Sass测试

If a test fails, Sass throws an error with @error

如果测试失败，Sass会使用@error引发错误

The Sass error is caught by Gulp which itself emits an error

Sass错误由Gulp捕获，Gulp本身发出错误 The Gulp error is caught by the pre-commit hook which aborts the commit

Gulp错误由预提交钩捕获，该钩将中止提交

So far, so good?

到目前为止，一切都很好？

设置测试架构 (Setting up the testing architecture)

The architecture word makes it sound so big while it actually is extremely simple. Here is what the project could look like:

架构字使它听起来非常大，而实际上却非常简单。 这是该项目的外观：

dist/ | |- my-sass-library.scss | tests/ | |- helpers/ | |- _SassyTester.scss | |- _custom-formatter.scss | |- function-1.scss |- function-2.scss |- ...

Not that impressive after all, heh? The Gulp task will simply run the Sass engines on all files in the tests folder. Here is what function-1.scss could look like:

毕竟没有那么令人印象深刻吗？ Gulp任务将仅在tests文件夹中的所有文件上运行Sass引擎。 这是function-1.scss样子：

// Import the library to test (or only the function if you can) @import '../dist/my-sass-library'; // Import the tester @import 'helpers/SassyTester'; // Import the custom formatter @import 'helpers/custom-formatter'; // Write the tests // See my previous article to know more about this: // http://... $tests-function-1: ( ... ); // Run the tests @include run(test('function-1', $tests-function-1));

Last but not least, we need to redefine the run(..) because the original one from SassyTester outputs the tests results with @error no matter whether they all pass or not. In our case, we only want to throw if there is an error. Let’s just put it in helpers/_output-formatter.scss.

最后但并非最不重要的一点是，我们需要重新定义run(..)因为来自SassyTester的原始结果会输出带有@error的测试结果，无论它们是否全部通过。 在我们的情况下，我们只想在出现错误时抛出。 让我们将其放在helpers/_output-formatter.scss 。

// We overwrite the `run(..)` mixin from SassyTester to make it throw // an `@error` only if a test fails. The only argument needed by the // `run(..)` mixin is the return of `test(..)` function from SassyTester. // You can check what `$data` looks like in SassyTester documentation: // http://hugogiraudel.com/SassyTester/#function-test @mixin run($data) { $tests: map-get($data, 'tests'); @each $test in $tests { @if map-get($test, 'fail') { @error 'Failing test! Expected : #{map-get($test, 'expected')} Actual : #{map-get($test, 'actual')}'; } } }

For a more advanced version of an equivalent run(..) mixin, check the one from include-media.

有关等效run(..) mixin的更高级版本，请从include-media检查该版本 。

Gulp工作流程 (The Gulp workflow)

If you want a short introduction to Gulp, please be sure to read my recent article about it: A Simple Gulpy Workflow for Sass. For this section, I’ll assume you’re familiar with Gulp.

如果您想对Gulp进行简短介绍，请确保阅读我最近关于它的文章： Sass的简单古尔比工作流程 。 在本节中，我假设您熟悉Gulp。

We need three tasks:

我们需要三个任务：

one to run LibSass on tests folder (using gulp-sass)

一个在tests文件夹上运行LibSass(使用gulp -sass )

one to run Ruby Sass on tests folder (using gulp-ruby-sass)

一个在tests文件夹上运行Ruby Sass(使用gulp-ruby-sass )

one to run the two previous tasks

一个来运行前两个任务 var gulp = require('gulp'); var sass = require('gulp-sass'); var rubySass = require('gulp-ruby-sass'); // Run LibSass on the tests folder // Gulp automatically exits process in case of Sass error gulp.task('test:libsass', function () { return gulp.src('./tests/*.scss') .pipe(plugins.sass()); }); // Run Ruby Sass on the tests folder // Gulp manually exits process in case of Sass error gulp.task('test:ruby-sass', function () { return rubySass('./tests') .on('error', function (err) { process.exit(1); }); }); gulp.task('test', ['test:libsass', 'test:ruby-sass']);

Ideally, when Sass throws an error (either because of a built-in error or because of @error), Gulp should exit properly. Unfortunately, there is an issue about this on gulp-ruby-sass that is still not fixed so for Ruby Sass, we have to raise a Node Uncaught Fatal Exception with process.exit(1) ourselves.

理想情况下，当Sass引发错误时(由于内置错误或@error )，Gulp应该正确退出。 不幸的是， 关于gulp-ruby-sass的问题仍然没有解决，因此对于Ruby Sass，我们必须使用process.exit(1)自己引发Node Uncaught Fatal Exception 。

添加一个预提交的钩子 (Adding a pre-commit hook)

There are tons of libraries to set up pre-commit hooks. I personally like pre-commit but you can basically choose the one you like as they all do more or less the same thing.

有大量的库可以设置预提交挂钩。 我个人喜欢预先提交，但是您基本上可以选择自己喜欢的一种，因为它们都或多或少地做同一件事。

To add a pre-commit hook to our project, we need to create a pre-commit key in our package.json. This key is mapped to an array of npm scripts commands. Thus, we also need a scripts object, with a key named test, mapped to the Gulp command: gulp test.

要将预提交钩子添加到我们的项目中，我们需要在package.json创建一个pre-commit密钥。 该密钥映射到npm脚本命令数组。 因此，我们还需要一个scripts对象，它的键名为test ，映射到Gulp命令： gulp test 。

"scripts": { "test": "gulp test" }, "pre-commit": ["test"]

When commiting, the pre-commit hook fires and tries to execute the test npm script. This script runs the following command: gulp test, which intimates Gulp to run the tests.

提交时，预提交挂钩会触发并尝试执行test npm脚本。 该脚本运行以下命令： gulp test ，它提示Gulp运行测试。

That’s it, we’re done.

就是这样，我们完成了。

最后的想法 (Final thoughts)

This example is extremely simplistic as you can see, but it does the job and it does it well. Here is what it might look like:

如您所见，该示例非常简单，但是可以完成工作并且做得很好。 可能是这样的：

So what do you think? Is this something you might consider adding to your library or framework?

所以你怎么看？ 您可以考虑将其添加到库或框架中吗？

翻译自: https://www.sitepoint.com/testing-sass-library/

sass导入sass