Jag bygger olika applikationer som oftast ser ut ungefär på följande sätt:

class Source {
JobData GetJobData();
JobDone(Result);
};

class Destination {
Result DoJob(JobData);
};

Source och destination kan vara databaser, filer, webbservice, special api:er etc
Triggningen av jobb kan ske via knapp i GUI, med timer, filesystemwatcher etc

Principen är enkel:
- Hämta jobb (Source.GetJobData)
- Utför jobb (Destination.DoJob)
- Rapportera jobb klart (Source.JobDone)

Frågan är hur jag bygger ihop ett system av det hela.

Kan tänka mig två olika vägar:

1. Särskild klass med oberoende source & destination
Main() {
jobdata = source.GetJobData();
result = destination.DoJob(jobdata);
source.JobDone(result)
}

2. Beroende source och destination (troligen med Interface)
Main() {
destination.DoJob(new Source);
eller
source.DoJob(new Destination);
}

I mina applikationer är jobdata/result alltid olika så source & destination delar på datatyper men anropar inte varandra.

När jag bygger applikationerna börjar jag enligt metod 1 ovan. Det blir då lätt att ta fram source och destinaton och de går att testa var för sig utan alltför mycket simulerande.

Tyvärr finns det nästan alltid något som stör symmetrin i systemet. Destination behöver fråga source om mer data för att kunna utföra jobbet eller måste rapportera tillbaka delar av jobbet innan allt är klart. Ibland finns det 2 source och/eller destination. Varje gång blir Main rutinen inbland.

Det blir då ungefär så här:
Source.GetJobData1();
Destination.DoJob();
if (Destination.Moredataneeded) {
Source.GetMoreJobData();
Destination.DoJobPart2();
}
...

Plötsligt blir det en massa svårtestad kod bara för att hålla isär source och destination. Speciellt krånglig blir felhanteringen. Om destination kastar ett undantag måste ändå den delen av jobbet som är klar rapporteras tillbaka till source (eller rapportera det som inte blev klart). Än värre blir det om source kastar undantag i GetMoreJobData...

Får alltid ihop det till slut men det blir aldrig några riktiga enhetstester av Main delen vilket irriterar mig
Har aldrig provat 2 för den känns så jobbig från början när man måste skapa interface och simulera source eller destination för att testa. Projekten är oftast små (10-20 timmar) så jag kan inte lägga för mycket tid på att bygga mocks.

Hoppas på att det finns någon smart lösning som jag inte tänkt på.

När jag snabbt läste genom ditt inlägg så ser det ut som att du skapar olika flöden. Har du funderat över att använda dig av Microsoft Workflow Foundation för detta?

Du skriver att du inte hinner skapa Mocks.. men du nämner att du skriver tester.. så med andra ord har du integration tester och det kräver ofta mer tid och erfarenhet att hanter dom rätt än att skapa stubbar och mock, bara en tanke ;)

När det gäller att skicka in fler source/destination, så kan du använda dig av Abstract Factory pattern http://www.dofactory.com/Patterns/PatternAbstract.aspx. Du kan använda dig av ett Dependecny Injection ramverk för att enkelt skapa upp dina beroenden och få automatiskt injection av sources och destinations.

Låter lite grann som "Saga:s" i NServiceBus...

http://www.udidahan.com/2008/02/04/sagas-and-unit-testing-business-process-verification-made-easy/

Tack för förslagen. WF kanske är det jag skall titta på. Det är iallafall en ny infallsvinkel.

Tidigare när jag tittat lite på WF har det dock känts lite omständigt. Skicka parametrar i dictionarys, skriva villkor i dialogrutor och sånt. För tillståndsmaskiner är det nog bra men för rena sekvenser vet jag inte.

Jag skall dock ta och prova med ett litet projekt jag har på gång och se var jag hamnar.

Någon som kan rekommendera en bok om WF.