14. BLAST¶

Als je als student een uitwerking van een exercise inlevert, wil je feedback krijgen. Binnen NexEd worden ingeleverde bestanden op de volgende manier gecontroleerd:

graph LR
  A@{ shape: sm-circ, label: "Small start" } --> B[BLAST testen];
  B --> C{Error?};
  C --> | Ja | D[Verbeteren]
  D --> C;
  C --> | Nee | E[Reviewen];
  E --> F{Issue?};
  F --> | Ja | G[Verbeteren];
  G --> F;
  F --> | Nee | H@{ shape: framed-circle, label: "Stop" };

1. BLAST testen: Ingeleverde codebestanden worden eerst automatisch getest op kwaliteit.
2. Reviewen: Vervolgens wordt de exercise handmatig nagekeken door een medestudent. ¹

Vóór het inleveren wordt automatisch gecontroleerd of codebestanden voldoen aan de standaarden binnen de industrie. De Basic Linter And Software Tester, beter bekend als BLAST, neemt dit voor zijn rekening.

14.1 Linters¶

Linten is het controleren van de kwaliteit van code, zonder naar de uitwerking te kijken. Zoals:

• Controleren of de haakjes { of } op de juiste plek staan.
• Controleren of de titel van een webpagina niet in het <header>-element staat.

BLAST is zelf geen linter, maar gebruikt bestaande, industriestandaard, linters om tot zijn conclusies te komen. De foutmeldingen die BLAST laat zien, komen dus niet van BLAST zelf, maar van deze bestaande tools. Als beginnend developer zijn deze foutmeldingen daarom vaak lastig om te lezen, maar met tijd went dit vanzelf.

Support – hieronder een overzicht van de verschillende talen die BLAST ondersteunt en de linter die per programmeertaal wordt gebruikt:

14.1.1 Foutmelding¶

Als één van de linting tools een fout detecteert, dan wordt je inleverpoging afgekeurd en wordt de fout weergegeven op de pagina. Alle fouten hebben een vaste opbouw, zoals te zien in de screenshot hieronder:

• De getallen voor Regel en Kolom geven aan waar in je codebestand de fout zich bevindt.
• Mocht je de foutmelding niet begrijpen, kun je hem googlen door op te klikken. Omdat BLAST standaard tools gebruikt, kan je online veel informatie vinden over de foutmeldingen.

14.2 Testen¶

Naast dat je uitwerking er goed uit moet zien, moet hij ook voldoen aan de eisen van de exercise. Dit kan zijn dat je bepaalde technieken hebt gebruikt (of juist verboden technieken niet) en dat je uitwerking met de juiste input en output geeft. Per exercise zijn er BLAST testen geschreven die de uitwerking downloaden, uitvoeren en verifiëren.

Precisie – de controles van deze testen zijn vaak heel gevoelig. Let goed op dat hoofdletters, leestekens, etc. precies overeenkomen met de uitkomst die BLAST verwacht:

14.2.1 Foutmelding¶

Als één van de tests een fout detecteert, dan wordt je inleverpoging afgekeurd en wordt de fout weergegeven op de pagina. Alle fouten hebben een vaste opbouw, zoals te zien in de screenshot hieronder:

• Titel: Een korte omschrijving van wat BLAST verwacht dat je doet. In dit geval verwacht BLAST dus dat we een variabele genaamd 'hoofdstad' maken.
• Menselijke foutmelding: Geeft iets uitgebreider aan wat BLAST van je verwacht. Deze staat er niet altijd bij, omdat de titel soms al genoeg informatie geeft.
• Technische foutmelding: Hier zie je wat er onder de motorkap gebeurt.

14.3 Limieten¶

Om misbruik van BLAST te voorkomen en 'gokken' van uitwerkingen tegen te gaan, zit er een limiet op het aantal inleverpoging per 10 minuten. Zodra je tegen deze limiet bent aangelopen, geeft NexEd hier tijdens het inleveren een melding over.