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!