Als simpele zien en niet professionele vind ik dit al tamelijk groot. Het is natuurlijk ook geen office365-online.
Voor wie antwoord. Hou het eerlijk en gebruik de juiste waarden 1KiB = 1024 Bytes.
CSS is niet zo belangrijk maar staat er bij voor de volledigheid.
Jan
?Onbekende gebruiker
19-08-2023 16:29
Ward van der Put op 16/08/2023 09:14:01
Het is eerder omgekeerd: bij elke update van PHP melden errors in de unit tests exact, op de regel nauwkeurig, welke code incompatibel is geworden. Ik ben er met PHP 5.3 in 2014 mee begonnen en dat heeft dus werk bespaard bij alle minor en major updates vanaf PHP 5.4 via PHP 7 naar nu PHP 8.2.
Het zere punt is natuurlijk dat je met de verandering van booleaanse logica in PHP 8 (ik begon er natuurlijk niet voor niets over) eigenlijk je hele code moet doorspitten en controleren of alle operatoren nog doen wat je verwacht. En alle code is dan ook inclusief de unit tests zelf, want dat is ook gemaakt in PHP. Dat is een ergernis, waardoor unit tests minder effectief kunnen zijn dan dat je zou verwachten.
Over het algemeen is het natuurlijk wel zo dat unit tests, zeker als onderdeel van TDD een effectieve manier is om software te ontwikkelen. De overhead betaalt zich uit (zij het minder met PHP maar toch). Een aantal bugs ben je in de initiële ontwikkelfase al voor, daarom vind ik TDD ook een goed idee.
De andere kant is dat de ontwikkelaar wel de ruimte moet hebben voor die overhead. En ik vind het lastig te bepalen waar het kantelpunt precies is. Omdat je algemeen gesproken met unit tests niet de afwezigheid van bugs kunt bewijzen, komt er nooit een einde aan de lijst van unit tests. Maar unit tests moet je net als code ook onderhouden, en er zijn ook nog andere tests.
Persoonlijk denk ik dat het genoeg is om een aantal unit tests te hebben die blokken code zou moeten testen op hun correcte werking, en een aantal om te laten zien tot waar de code werkt, wanneer het fout zou moeten gaan.
Qua grootte denk ik dat de hoeveelheid code voor unit tests niet groter zou moeten zijn (los van documentatie) dan de code die getest wordt.
Wat denk jij Ward, is in jouw geval die verhouding ook 1:1 ?
Documentatie is in mijn geval een veelvoud van de code. Naast dat elke functie gedocumenteerd is in de code, heb je allerlei aanvullende documentatie, standaarden, handleidingen, ontwikkelhandleidingen, beleid, procedures en ga zo maar door.
Qua grootte denk ik dat de hoeveelheid code voor unit tests niet groter zou moeten zijn (los van documentatie) dan de code die getest wordt.
Wat denk jij Ward, is in jouw geval die verhouding ook 1:1?
Ik denk dat je moet streven naar minstens 1:1.
Als we ervan uitgaan dat één regel code precies één ding doet, dan heb je minstens één assertion nodig om de juistheid van je programma te bewijzen.
Dat is wat code coverage ook controleert: wordt elke regel code wel 'gedekt' door je test suite? Dat zegt echter alleen iets over de omvang van je tests, niet over de kwaliteit.
Er zijn veel situaties denkbaar waarbij je méér tests dan code hebt, vooral als je state erbij betrekt. Eenvoudig voorbeeld: om de juistheid van één simpele tinyint te bewijzen, heb je drie assertions nodig, namelijk assertIsInt(), assertGreaterThan() en assertLessThan().
Als je unit tests gebruikt om te debuggen, krijg je bovendien een heleboel tests die overbodig lijken omdat ze het onmogelijke bewijzen: ze tonen aan dat een bug niet meer optreedt. Toch laat je vooral die ogenschijnlijk overbodige tests staan, juist om te voorkomen dat de bug ooit terugkeert.
?Onbekende gebruiker
22-08-2023 19:00
gewijzigd op 22-08-2023 19:01
Duidelijk standpunt, ik kan me daar in wel verplaatsen.
En hoe test je (complexe) queries? Ook op dezelfde manier, met meerdere scenario's?
Ik heb ook nog een groep functies die redelijk op elkaar lijken. Ik zou ze kunnen normaliseren, maar dan moet de code dynamisch worden en uit de database opgehaald. Uitzonderingen toevoegen wordt dan ook veel lastiger.
Hoe test je die code, die je ook prima op het oog kunt doorzien? Zou je daar ook allemaal unit tests voor gaan schrijven?
Ik denk dat het in mijn geval nog gaat schuiven, omdat de software requirements (van het ontwerp) de hele tijd veranderen. Dat is niet iets dat ikzelf bepaal, dat komt van de business.
?Onbekende gebruiker
03-09-2023 22:38
gewijzigd op 03-09-2023 22:41
Er zijn veel situaties denkbaar waarbij je méér tests dan code hebt, vooral als je state erbij betrekt. Eenvoudig voorbeeld: om de juistheid van één simpele tinyint te bewijzen, heb je drie assertions nodig, namelijk assertIsInt(), assertGreaterThan() en assertLessThan().
Kleine aanvulling nog: je voorbeeld over unit tests is niet heel illustratief. Als je in PHP voor elke INT een unit test moet gaan doen vanwege het weak type system, zit je gewoon in de verkeerde taal. Een andere taal geeft meteen een error in de IDE nog voordat je de code uitvoert, zelfs als de integer overflowt. En als het voor de database is, dan is een isInt test ook maar 1x handig, tenminste als je het object-georiënteerd doet.
Een parser of linter kan bijvoorbeeld deze fout niet herkennen (en een IDE zoals VS Code out-of-the-box ook niet):
<?php
declare(strict_types=1);
class FooBar implements \Countable
{
public float $counter;
public function count(): int
{
return $this->counter;
}
}
?>
De code is fout, maar je kunt tijdens het programmeren niet blindvaren op parser, linter, strict typing of IDE. De fout zal gegarandeerd opduiken zodra je de code uitvoert en die zekerheid biedt een unit test.
Unit testing is zeker geen zaligmakende totaaloplossing. Met static analysis kun je deze specifieke fout ook vinden. Bijvoorbeeld PHPStan herkent de bug direct: probeer zelf maar... ;-)
