Hirdetés
- hcl: Máté tíz pró
- Brogyi: CTEK akkumulátor töltő és másolatai
- f(x)=exp(x): A laposföld elmebaj: Vissza a jövőbe!
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Luck Dragon: Asszociációs játék. :)
- Parci: Milyen mosógépet vegyek?
- sziku69: Fűzzük össze a szavakat :)
- btz: Internet fejlesztés országosan!
- sziku69: Szólánc.
- eBay-es kütyük kis pénzért
Új hozzászólás Aktív témák
-
Szmeby
tag
"Vannak ValamiTask osztályaim, amik mindegyike tartalmaz egy doAction metódust, és az tartalmazza az üzleti logikát, valamint a commander meghívását.
[..]
Hogy oldom meg a TaskTest osztály testDoAction metódusában, hogy az ott példányosított Task osztály doAction függvényében meghívott commander osztály mock objektumokat használjon? Tehát két hívásra to"le."Hát leküldöd neki.
Bár nem látom, hol van itt a második réteg.Ezekszerint nem ilyen a design:
public class Task {
private Commander cmd;
public Task(Commander commander) {
cmd = commander;
}
public doAction() {
// using cmd
}
}Tesztelhetőség szempontjából ilyesmi lenne a célravezető. Konstruktor argumentumként adod le neki a mockot, vagy a mockokat használó Commander példányt és azt csinál majd vele, amit csak akar.
-
boost
veterán
Ja, és az én "rossz" megoldásom az lenne, hogy lebontani ezeket a rétegek beanekre, és akkor lehetne távolról is több rétegen át injektálni a mock-objekumokat.
A szerintem jó megoldás, hogy el kell engedni a többrétegu" unit teszteket, hisz a unit teszt arra van, hogy azt a metódust tesztelje, az abban levo"üzleti logikát, és nem a metódus által meghívott metódusokat, szóval ebben az esetben a commander hívás már egy mock commander lesz. és csak arra koncentrálok, hogy mikor, és hányszor lett meghívva a mock kommander, és ez az eredmény megfelel-e annak, amit vártunk to"le.
Új hozzászólás Aktív témák
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest