Testen einer Sass -Bibliothek

In letzter Zeit habe ich eine anständige Zeit damit verbracht, mit Eduardo Bouças auf Include-Media zu arbeiten. Wir haben viel Refactoring durchlaufen, also beschlossen, einige Tests zu schreiben und sie in jedem Commit durchzuführen, um sicherzugehen, dass wir nichts gebrochen haben. Ich werde die Details in diesem Artikel durchgehen.

Wenn Sie noch nicht wissen, dass es include-media ist, ist es ein sehr leicht und dennoch leistungsstarker Breakpoint-Manager in SASS.

Die bereitgestellte öffentliche API ist ein einzelner Mixin, Medien (..) (daher der Name der Bibliothek), aber das Ganze ist gut genug gedacht, damit Sie tatsächlich Wunder damit tun können. Ein kurzes Beispiel vor dem Beginn:

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

Das ist ziemlich rad, oder?

Wie auch immer, also haben wir ein kleines Testsystem entwickelt, das ich gerne mit euch teilen möchte. Wenn Sie ein vollständiges Framework testen möchten, sollten Sie stattdessen TRUE von Eric Suzanne verwenden, was ein in Sass geschriebenes volles Test -Rahmen für SASS ist und von David in einem kürzlich auf SitePoint vorliegenden Artikel vorgestellt und erklärt wurde.

Was ist die Idee?

Wir wollten ein paar Tests über die Hauptfunktionen der Hauptbibliothek aus der Bibliothek durchführen, wenn wir uns zum Repository verpflichten. Wenn ein Test fehlschlägt, wird das Komitee abgebrochen und der Code muss behoben werden, damit das Verabschiedung das Verabschiedung ermöglicht. Auf diese Weise stellen wir sicher, dass wir sicher in der Bibliothek arbeiten können, ohne sie zu brechen (was normalerweise ein schlechtes ist).

so etwas wie dieses war überraschend einfach: Wir haben einen Pre-Commit Git-Hook eingerichtet, um Tests sowohl in libsass als auch in Ruby-Sass vor dem Vorgehen durchzuführen. Wenn der Test fehlschlägt, töten wir den Prozess.

Es gibt verschiedene Möglichkeiten, Sass und Libsass zu betreiben. Sie können entweder Binärdateien haben oder einen Wrapper verwenden. In unserem Fall haben wir uns für einen winzigen Gulp -Workflow entschieden, was es uns leicht macht, sowohl Ruby Sass als auch Libas zu laufen.

Wir wollten etwas sehr Einfaches, daher werden Tests mit Sassytester in SASS geschrieben, die ich kürzlich im Artikel in 5 Minuten getestet habe, um eine SASS -Funktion zu testen. Sassytester ist ungefähr 25 Zeilen lang. Die Testfunktion gibt nur eine SASS -Karte mit den Ergebnissen aus den Tests aus. Von dort aus können wir alles tun, was wir wollen. In unserem Fall möchten wir einen Fehler werfen, wenn ein Test fehlschlägt. Dazu haben wir die @Error -Richtlinie von Sass!

Beim Kompilieren der SASS-Tests, wenn die Gulp-Aufgabe auf einen SASS-Fehler trifft, verlässt sie den Prozess, während er selbst einen Fehler auswirft, der sich bis zum Vorkommiten-Haken auswirkt und schließlich das Komitee abbricht.

Wenn wir dies zusammenfassen, geht es so:

1. Ein Pre-Commit-Hook führt eine Test-Gulp-Aufgabe in Commit
aus
2. Die Test -Gulp -Aufgabe erstellt SASS -Tests sowohl in libsass als auch in Ruby Sass
Wenn ein Test fehlschlägt, wirft SASS einen Fehler mit @Error
4. aus
Der SASS -Fehler wird von Gulp erfasst, der selbst einen Fehler ausgibt
Der Gulp-Fehler wird vom Pre-Commit-Haken erfasst, der das Commit

abbricht

so weit, so gut?

Einrichten der Testarchitektur

Die Architektur

Wort klingt so groß, während es tatsächlich extrem einfach ist. So könnte das Projekt aussehen:

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

Nicht so beeindruckend, heh? In der Gulp -Aufgabe werden die Sass -Motoren einfach in allen Dateien im Ordner Tests ausgeführt. Hier ist, was Funktion-1.Scss aussehen könnte:

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

Zu guter Letzt müssen wir den Lauf (..) neu definieren (..), da das Original von Sassytester die Tests mit @Error ausgibt, unabhängig davon, ob sie alle bestehen oder nicht. In unserem Fall möchten wir nur dann werfen, wenn ein Fehler vorliegt. Lassen Sie es einfach in Helpers/_output-formatter.scss.

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

einfügen.

für eine fortgeschrittenere Version eines äquivalenten Laufs (..) Mixin, überprüfen Sie die von include-media.

Der Gulp Workflow

Wenn Sie eine kurze Einführung in Gulp wünschen, lesen Sie bitte meinen letzten Artikel darüber: einen einfachen Gulpy -Workflow für SASS. Für diesen Abschnitt gehe ich davon aus, dass Sie mit Gulp vertraut sind.

Wir brauchen drei Aufgaben:
• eins, um libsass auf dem Testsordner (mit Gulp-Sass)
auszuführen
eins zum Ausführen von Ruby Sass im Testsordner (unter Verwendung von Gulp-Ruby-Sass)

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

eins, um die beiden vorherigen Aufgaben auszuführen

Idealerweise sollte Gulp idealerweise ordnungsgemäß beenden. Leider gibt es ein Problem damit bei Gulp-Ruby-Sass, das noch nicht behoben ist. Für Ruby Sass müssen wir einen Knoten

mit Prozess

mit Prozess (1) selbst nicht erfassen.

Hinzufügen eines Pre-Commit-Hooks Es gibt unzählige Bibliotheken, um Pre-Commit-Haken einzurichten. Ich persönlich mag Pre-Commit, aber Sie können im Grunde diejenigen wählen, die Sie mögen, da sie alle mehr oder weniger dasselbe tun.

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

Um unserem Projekt einen Pre-Commit-Haken hinzuzufügen, müssen wir in unserem Paket.json einen Taste vor dem Kommando erstellen. Dieser Schlüssel wird einem Array von

npm -Skripten

-Hellbefehl zugeordnet. Somit benötigen wir auch ein Skriptsobjekt mit einem Schlüssel mit dem Namen, der dem Gulp -Befehl zugeordnet ist: Gulp -Test.

Im Voraus feuert der Pre-Commit-Haken und versucht das Test-NPM-Skript auszuführen. In diesem Skript wird der folgende Befehl ausgeführt: Gulp -Test, der den Gulpen für die Ausführung der Tests erhöht.

Das ist es, wir sind fertig.

endgültige Gedanken

Dieses Beispiel ist äußerst simpel, wie Sie sehen können, aber es macht den Job und macht es gut. So könnte es aussehen:

Was denkst du? Ist dies etwas, das Sie in Betracht ziehen könnten, in Ihre Bibliothek oder Ihr Framework hinzuzufügen?

Das obige ist der detaillierte Inhalt vonTesten einer Sass -Bibliothek. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!