Unit testen

[Verwijderd]

Ik ben bezig met een PHP MVC Frameworkje op te zetten om PHP nog beter onder de knie te krijgen en wil eigenlijk ook graag gebruik maken van unit testen. Nou is mijn vraag misschien wel heel simpel, maar toch;

Moet ik nou de Models testen of de Controllers of is het beter om beide te testen?

Alvast bedankt.

[Janoz]

Wat zou je aan je model willen testen? Iin principe is dat niet meer dan een container van je data. Om nu je getters en setters te gaan teten lijkt mij wat overbodig.

[!null]

Model en View valt als het goed is niet veel aan het testen, okee de mechanismes misschien een keer. Daarna meer op de control logica, wat je toch wil opdelen in onderdelen (units) van je systeem.

[Verwijderd]

Ik dacht er aan om de models te testen omdat deze bij mij ook functies bevatten die insert, update en delete queries uitvoeren.

[ Voor 68% gewijzigd door Verwijderd op 25-11-2009 10:20 ]

[Janoz]

Die functies zullen zeker getest moeten worden, maar de model is niet de plek waar die functies thuishoren. Over het algemeen horen die functies thuis in de data/service laag. Je controler roept die laag aan en deze leveren de content voor het model op.

[Standeman]

Verwijderd schreef op woensdag 25 november 2009 @ 10:14:
Ik dacht er aan om de models te testen omdat deze bij mij ook functies bevatten die insert, update en delete queries uitvoeren.

Die moet je zeker testen.

Maar als je helemaal "goed" wilt doen zou je eigenlijk een aparte data access laag moeten schrijven. De model objecten in het MVC pattern zijn over het algemeen vrij domme dingen en zouden eigenlijk niets van data access af moeten weten ("low coupling, high cohesion" in OO taal).
Eigenlijk zou het hele MVC pattern zich alleen zorgen moeten maken om het presenteren van gegevens aan de gebruiker en het verwerken van input.

[ Voor 5% gewijzigd door Standeman op 25-11-2009 10:26 ]

[Verwijderd]

Een kort voorbeeld van een nieuwsbericht om aan te geven waar mijn functies zich bevinden.

In het NewsModel heb ik de volgende functie staan:

code:

/**
/* Get Newsitem by id.
**/
function getNews($id) {
    return database::selectAll("news", "WHERE id = '". $id . "'");
}

In de controller roep ik deze methode aan en geef ik het resultaat door richting de view. Dat doe ik als volgt:

code:

assign("nieuws", $newsModel->getNews($id) );

Is dit ook hoe jij het bedoeld Janoz of heb ik de functies niet op een geheel logische plek staan?

[Janoz]

Het model zou juist een newsItem moeten representeren. Die functie die je daar hebt zou beter thuis passen in een NewsRepository of NewsDao.

[Verwijderd]

En wat moet ik mij precies voorstellen bij een newsItem representeren, hoe zou het model er dan kort samengevat uitzien?

[YopY]

Verwijderd schreef op woensdag 25 november 2009 @ 10:56:
En wat moet ik mij precies voorstellen bij een newsItem representeren, hoe zou het model er dan kort samengevat uitzien?

Redelijk eenvoudig:

PHP:

class Article extends Model {
 private Title;
 private Subtitle;
 private ArticleBody;
 private PublicationDate;

// getters / setters voor variabelen
}

(geen idee of dit valide PHP is, tijdje geleden). De 'model' class (Article, in dit geval) bevat slechts de artikeldata en eventueel eenvoudige functies die iets ermee doen (bijvoorbeeld een resetPublicationDate die de publicatie datum op 'nu' zet).

Daarnaast maak je een ArticleDao (Data Access Object) met functies zoals find($articleId), findByTitle($articleTitle), getAll, getAll($offset, $limit), en ga zo maar door.

[!null]

Hoe zijn jullie eigenlijk die data access laag, schuif je die onder de Controller of niet? Als je het puur over MVC ideologie hebt.

[Verwijderd]

Bedankt voor je uitleg YopY. Ik heb het model eigenlijk het zelfde als dat jij uitlegt, alleen bevat mijn model dus nog iets te veel functies. Deze kan ik dus beter opsplitsen naar een DAO, de reden hiervoor zal waarschijnlijk zijn dat een ander model eenvoudig gebruik kan maken van hetzelfde DAO. Dat is de reden toch?

[Standeman]

!null schreef op woensdag 25 november 2009 @ 11:02:
Hoe zijn jullie eigenlijk die data access laag, schuif je die onder de Controller of niet? Als je het puur over MVC ideologie hebt.

De standaard 3 tier applicatie bestaat uit een data, model en presentatie tier.
Het MVC pattern past imo eigenlijk alleen in de presentation tier van je applicatie en zorgt voor o.a. pageflow en conversie van de data op je pagina naar de model laag. Hierbij moet je oppassen dat je de model van het MVC pattern niet verward met het model laag.

Maar goed, dat is een draai die ik er zelf een beetje aan heb gegeven.

Verwijderd schreef op woensdag 25 november 2009 @ 11:04:
Bedankt voor je uitleg YopY. Ik heb het model eigenlijk het zelfde als dat jij uitlegt, alleen bevat mijn model dus nog iets te veel functies. Deze kan ik dus beter opsplitsen naar een DAO, de reden hiervoor zal waarschijnlijk zijn dat een ander model eenvoudig gebruik kan maken van hetzelfde DAO. Dat is de reden toch?

Yup, dat is de reden. Tevens zal je ook merken dat je code een stuk makkelijk de unit-testen wordt

[ Voor 26% gewijzigd door Standeman op 25-11-2009 11:16 ]

[Verwijderd]

Standeman schreef op woensdag 25 november 2009 @ 11:15:
Yup, dat is de reden. Tevens zal je ook merken dat je code een stuk makkelijk de unit-testen wordt

Goed om inderdaad weer even terug te komen op het unit-testen. Klopt het dat de controller nu aan een DAO bijvoorbeeld alle nieuwsberichten opvraagt? En moet ik met deze verandering in de architectuur ook nog steeds de controller blijven testen?

[Janoz]

Alle stukken met logica zul je moeten testen, en aangezien je controler logica bevat zul je die ook moeten testen. Vaak wordt (omdat het een unit test is) een dao mock aan de controler gehangen en dan gekeken of een aanroep bij de controler op de mock aankomt en het resultaat van de mock op de juiste manier weer uit de aanroep bij de controler komt.

[Standeman]

Janoz schreef op woensdag 25 november 2009 @ 11:35:
Alle stukken met logica zul je moeten testen, en aangezien je controler logica bevat zul je die ook moeten testen. Vaak wordt (omdat het een unit test is) een dao mock aan de controler gehangen en dan gekeken of een aanroep bij de controler op de mock aankomt en het resultaat van de mock op de juiste manier weer uit de aanroep bij de controler komt.

En dan is het weer handig om een mocking framework te gebruiken zoals jMock of Mockito. Daarmee kan je dus de onderliggende laag "nadoen".

[ Voor 4% gewijzigd door Standeman op 25-11-2009 11:49 . Reden: Ik was even in Java sferen en vergeten dat je met PHP bezig was ]

[Verwijderd]

Iemand al ervaring met SimpleTest eigenlijk? Want ik zie dat zij ook mock objecten ondersteunen.

[Janoz]

Standeman schreef op woensdag 25 november 2009 @ 11:46:
[...]

En dan is het weer handig om een mocking framework te gebruiken zoals jMock of Mockito. Daarmee kan je dus de onderliggende laag "nadoen".

Precies, maar ik vraag me af hoe volwassen mocking frameworks in php zijn (en dat bedoel ik niet denigrerend, maar vooral dat ik echt benieuwd ben hoe ver ze al zijn). Zelf gebruik ik vaak EasyMock, maar dat is voor java. Het belangrijkste bij unittests is dat je voornamelijk met het schrijven van de daadwerkelijke test bezig zou moeten zijn. Als je te lang met het maken van mocks en het aan elkaar rijgen van je test setup bezig bent verdwijnt de motivatie om goede tests te schrijven.

[Standeman]

offtopic:
Ik vraag me af in hoeverre PHP zich uberhaupt verhoudt tot Java / C# als OO platform. Ik kom het wel steeds vaker tegen en het lijkt erop dat er flink aan de weg getimmerd wordt.