Jest aplikacja, która przerabia artykuł bloga na teaser, czyli taki skrót, zajawkę. Zwraca zadaną ilość znaków licząc od początku. W przypadku, gdy ucięcie pada pomiędzy tagami <code></code>, które mogą się znaleźć w artykule, domyka wszystkie rozpoczęte tagi a niezamknięte tagi pomiędzy tagami <code> i dodaje na koniec domknięcie dla <code>.

Czyli aplikacja tak schludnie ucina zawartą w artykule bloga prezentację kodu. Nie tworzą się krzaczki tylko ładny zhajlajtowany tekst ucięty gdzieś tam wewnątrz kodu.

Czy taką aplikację powinno się przetestować czymś takim jak phpunit? Jeśli tak, to co by taki test robił? Bo test mógłby sprawdzać wynik dla kolejnych długości tego teasera, od 1 do 1000 np. Tylko jaką funkcją potem sprawdzić, że nie ma niedomkniętych tagów?

Może w ogóle jakoś inaczej to testować, a może taka aplikacja nie podlega testowaniu?
Z góry dziękuję

Jak najbardziej powinno zostać to mocno przetestowane na możliwie dużej liczbie przypadków testowych. Jak mógłby wyglądać test?

[PHP] pobierz, plaintext 
$obj = new MyClass(50); // usługa skracająca tekst do 50 znaków
$content = '<p>Blah blah blah blah blah</p><code>some code some code some code some code some code some code some code some code some code</code>';
 
$result = $obj->createTeaser($content);
 
$this->assertEqual('<p>Blah blah blah blah blah</p><code>some code some code some...</code>', $result);
[PHP] pobierz, plaintext 

Oczywiście to tylko jedne z przypadków testowych, których tutaj zapewne będziesz potrzebować dziesiątki.

Rozumiem, ale jeszcze muszę o coś spytać. Za pośrednictwem funkcji assertEqual będzie sprawdzana identyczność stringa spodziewanego i stringa wynikowego aplikacji.

Ten string spodziewany to muszę "na piechotę" określić? Przy kilkudziesięciu testach muszę określić "na piechotę" kilkadziesiąt spodziewanych stringów?

W skrócie: tak - test musi skądś wiedzieć jaka wartość jest uznawana za odpowiednią/wzorcową.

Ok, dzięki za pomoc. Gdyby ktoś jeszcze miał jakiś pomysł, to śmiało.

niedomknięte tagi naprawia tidy http://php.net/manual/en/tidy.repairstring.php

Zastosowałem mechanizm regenerujący DOMDocument zamiast tidy. Jest większa kontrola nad wynikowym stringiem. W tidy napotkałem na schody i pewnie musiałbym sporo rozkminiać w konfiguracji tidy, żeby ogarnąć.

W każdym razie
1. tidy dodaje przełamanie linii na końcu zwracanego kodu.
2. Dodanie zamykającego tagu ok, ale jeszcze przed tym domykającym tagiem trza dodać '...'. Przy zagnieżdzonym domykaniu tagów dodanie 3 kropeczek musi być też zagnieżdżone.

Aczkolwiek nie kwestionuję, że tidy może też tu starczyć.

Przydatne mogą się okazać także asercje assertContains, assertRegExp, assertStringMatchesFormat oraz utworzenie plików z fixturami, datasetów itp.