[Clarence]

Ursprungligen postat av dAEk

Så tänkte jag också men så lät jag det sjunka in lite.
Skall man vara strikt skall ju TDD forma koden och det verkar krocka med DDD som jag förstår det. Det kanske är det Conny menar?

Tester kan man såklart ha i DDD också.

Håller inte med. Läser du ut TDD som en test driven design så har du gått ifrån dess ursprungliga mening och borde därmed ta tid att förklara vad du menar.

[dAEk]

Ursprungligen postat av Clarence

Håller inte med. Läser du ut TDD som en test driven design så har du gått ifrån dess ursprungliga mening och borde därmed ta tid att förklara vad du menar.

Jag menar inte att man kan strunta i arkitekturen utan mer att man har den i åtanke när man kodar. I TDD utgår man (läs. jag) från testerna, klasserna designas löpande i takt med att beroenden tillkommer; DDD verkar ha vissa förutbestämda klossar som man utgår från. Vet inte om min bild är skev men det är så jag ser på det.

[Clarence]

Ursprungligen postat av dAEk

Jag menar inte att man kan strunta i arkitekturen utan mer att man har den i åtanke när man kodar. I TDD utgår man (läs. jag) från testerna, klasserna designas löpande i takt med att beroenden tillkommer; DDD verkar ha vissa förutbestämda klossar som man utgår från. Vet inte om min bild är skev men det är så jag ser på det.

Såsom jag ser det förändrar det bara vad och hur man testar. Du testar inte states utan beteende. Det finns mycket att läsa om kombinationen TDD DDD - dess svårigheter och best practices. Det finns även en mängd exempel-projekt på github som ger lite hints om man är mer praktiskt lagd.

Dock skulle jag vilja säga att DDD sällan (dvs mer än aldrig men mindre än ofta!) är sunt och TDD alltid är sunt.