it-swarm-eu.dev

Mám testovat soukromé metody nebo pouze ty veřejné?

Četl tento příspěvek o tom, jak testovat soukromé metody. Obvykle je netestuji, protože jsem si vždycky myslel, že je rychlejší testovat pouze veřejné metody, které budou volány zvenčí. Testujete soukromé metody? Mám je vždy otestovat?

300

Nechci testovat soukromé metody. Soukromá metoda je implementační detail, který by měl být skrytý pro uživatele třídy. Testování soukromých metod přerušuje zapouzdření.

Pokud zjistím, že soukromá metoda je obrovská nebo složitá nebo dostatečně důležitá na to, aby vyžadovala vlastní testy, vložím ji do jiné třídy a zveřejním ji ( Method Object ). Pak můžu snadno otestovat dříve soukromou, ale nyní veřejnou metodu, která nyní žije ve své vlastní třídě.

289
jop

Jaký je účel testování?

Většina odpovědí doposud říká, že soukromé metody jsou implementační detaily, které nezáleží (nebo přinejmenším by neměly), pokud je veřejné rozhraní testováno a funkční. To je naprosto správné pokud je vaším jediným účelem testování zaručit, že veřejné rozhraní funguje .

Osobně jsem primárně použil pro testy kódu, aby bylo zajištěno, že budoucí změny kódu nezpůsobí problémy a pomůžou s laděním, pokud ano. Zjistil jsem, že testování soukromých metod stejně důkladně jako veřejné rozhraní (ne-li více)!.

Zvažte: Máte veřejnou metodu A, která volá privátní metodu B. A a B oba používají metodu C. C je změněna (možná vy, možná dodavatelem), což způsobuje, že A začne selhat v testech. Nebylo by užitečné mít také testy na B, i když je to soukromé, takže víte, zda je problém použití C, B v C nebo obojí?

Testování soukromých metod také přidává hodnotu v případech, kdy je pokrytí testem veřejného rozhraní neúplné. I když se jedná o situaci, které se obecně chceme vyhnout, testování účinnosti jednotky závisí jak na testech, které hledají chyby, tak na souvisejících nákladech na vývoj a údržbu těchto testů. V některých případech mohou být přínosy 100% pokrytí testem považovány za nedostatečné k tomu, aby odůvodňovaly náklady na tyto testy, což vede k mezerám v pokrytí testů veřejného rozhraní. V takových případech může být velmi účelným doplňkem kódové základny dobře cílený test soukromé metody.

270
Dave Sherohman

Mám tendenci následovat radu Davea Thomase a Andyho Hunta v jejich knize Pragmatic Unit Testing :

Obecně, nechcete rozbít žádné zapouzdření kvůli testování (Nebo jak maminka říkala, "nevystavujte své priváty!"). Většinu času byste měli být schopni otestovat třídu pomocí svých veřejných metod . Pokud existuje významná funkce, která je skrytá Za soukromým nebo chráněným přístupem, mohlo by to být varovným signálem, že tam je další třída, která se snaží dostat ven.

Někdy se ale nemohu zastavit v testování soukromých metod, protože mi to dává pocit jistoty, že budu úplně robustní program.

136

Cítím, že jsem nucen otestovat soukromé funkce, protože sleduji stále více a více jednoho z našich nejnovějších doporučení QA v našem projektu:

Ne více než 10 v cyklomatická složitost na funkci.

Vedlejším efektem prosazování této politiky je to, že mnoho mých velmi velkých veřejných funkcí je rozděleno do mnohem více zaměřené, lépe pojmenované funkce private.
Veřejná funkce stále existuje (samozřejmě), ale je v podstatě omezena na všechny tyto „dílčí funkce“.

To je vlastně v pohodě, protože callstack je nyní mnohem snazší číst (místo chyby v rámci velké funkce, mám chybu v sub-sub-funkci s názvem předchozích funkcí v callstacku, aby mi pomohl pochopit "jak jsem se tam dostal")

Nyní se však zdá být snazší přímo testovat funkce těchto soukromých a zanechat testování velké veřejné funkce nějakému testu „integrace“, kde je třeba řešit scénář.

Jen moje 2 centy.

58
VonC

Ano, testuji soukromé funkce, protože i když jsou testovány vašimi veřejnými metodami, je hezké v TDD (Test Driven Design) otestovat nejmenší část aplikace. Ale soukromé funkce nejsou přístupné, když jste ve třídě testovací jednotky. Zde je to, co děláme, abychom otestovali naše soukromé metody.

Proč máme soukromé metody?

Soukromé funkce existují především v naší třídě, protože chceme vytvářet čitelné kódy v našich veřejných metodách. Nechceme, aby uživatel této třídy zavolal tyto metody přímo, ale prostřednictvím našich veřejných metod. Také nechceme měnit jejich chování při rozšiřování třídy (v případě chráněných), proto je to soukromé.

Když jsme kód, používáme test-driven-design (TDD). To znamená, že někdy narazíme na funkci, která je soukromá a chcete ji otestovat. Soukromé funkce nejsou v phpUnit testovatelné, protože k nim nemůžeme přistupovat ve třídě Test (jsou soukromé).

Myslíme si, že zde jsou 3 řešení:

1. Své priváty můžete otestovat prostřednictvím veřejných metod

Výhody

  • Přímé testování jednotek (není třeba žádné „hacky“)

Nevýhody

  • Programátor musí pochopit veřejnou metodu, zatímco chce pouze otestovat soukromou metodu
  • Nejste testování nejmenší testovatelné části aplikace

2. Pokud je soukromý server tak důležitý, pak je možné, že se jedná o kód pro vytvoření nové oddělené třídy

Výhody

  • Můžete to přepočítat na novou třídu, protože pokud je to důležité, mohou ji potřebovat i jiné třídy 
  • Testovatelná jednotka je nyní veřejnou metodou, která je tak ověřitelná

Nevýhody

  • Nechcete vytvořit třídu, pokud ji nepotřebujete, a používá ji pouze třída , Kde metoda pochází z
  • Potenciální ztráta výkonu z důvodu přidané režie

3. Změňte modifikátor přístupu na (konečné) chráněné

Výhody

  • Testujete nejmenší testovatelnou část aplikace. Při použití S použitím finální ochrany nebude funkce přepsatelná (jen Jako soukromá)
  • Žádná ztráta výkonu
  • Žádné další režijní náklady

Nevýhody

  • Měníte soukromý přístup k chráněným, což znamená, že je Přístupné jeho dětem
  • Stále potřebujete třídu Mock ve své testovací třídě, abyste ji mohli použít

Příklad

class Detective {
  public function investigate() {}
  private function sleepWithSuspect($suspect) {}
}
Altered version:
class Detective {
  public function investigate() {}
  final protected function sleepWithSuspect($suspect) {}
}
In Test class:
class Mock_Detective extends Detective {

  public test_sleepWithSuspect($suspect) 
  {
    //this is now accessible, but still not overridable!
    $this->sleepWithSuspect($suspect);
  }
}

Takže naše testovací jednotka nyní může zavolat test_sleepWithSuspect, aby otestovala naši dřívější soukromou funkci.

48
eddy147

Myslím, že je nejlepší testovat veřejné rozhraní objektu. Z hlediska vnějšího světa je důležité pouze chování veřejného rozhraní a to je to, na co by měly být zaměřeny vaše testy jednotek.

Jakmile máte nějaké testy pevných jednotek napsané pro objekt, nechcete se vrátit zpět a změnit tyto testy jen proto, že implementace za rozhraním se změnila. V této situaci jste zničili konzistenci testování jednotky.

23
17 of 26

Je-li soukromá metoda dobře definována (tj. Má funkci, která je testovatelná a nemá se měnit v čase), pak ano. Testuji vše, co je testovatelné tam, kde to dává smysl.

Knihovna šifrování může například skrýt skutečnost, že provádí šifrování bloků soukromou metodou, která šifruje pouze 8 bajtů najednou. Já bych za to napsal jednotkový test - není to míněno ke změně, i když je to skryté, a pokud se to rozbije (například kvůli budoucím vylepšením výkonu), pak chci vědět, že je to soukromá funkce, která se rozpadla, ne jen že jedna z veřejných funkcí se rozpadla.

Zrychluje ladění později.

- Adam

19
Adam Davis

Pokud vaše soukromá metoda není testována voláním svých veřejných metod, pak to, co to dělá? Mluvím o soukromí, který není chráněn nebo přítel.

17
chrissie1

Pokud vyvíjíte test (TDD), otestujete své soukromé metody.

12
Jader Dias

Nejsem odborník v této oblasti, ale testování jednotek by mělo testovat chování, ne implementaci. Soukromé metody jsou přísně součástí implementace, proto by neměl být testován IMHO.

11
maxbog

Testujeme soukromé metody odvozením, což znamená, že hledáme pokrytí testů v celkové třídě alespoň 95%, ale pouze naše testy zavoláme do veřejných nebo interních metod. Abychom dosáhli pokrytí, potřebujeme několikrát zavolat na veřejnost/interiéry na základě různých scénářů, které mohou nastat. Díky tomu jsou naše testy úmyslnější, pokud jde o účel kódu, který testují.

Trumpiho odpověď na příspěvek, který jste propojili, je nejlepší.

11
Tom Carr

Věřím, že jednotkové testy jsou určeny pro testování veřejných metod. Vaše veřejné metody používají vaše soukromé metody, takže se nepřímo testují.

8
scubabbl

Chvíli jsem nad tímhle problémem dusil, hlavně když jsem se snažil držet TDD.

Narazil jsem na dvě pracovní místa, o nichž se domnívám, že tento problém řeší dostatečně důkladně v případě TDD.

  1. Testování soukromých metod, TDD a Test-Driven Refactoring
  2. Vývoj testů není testován

Celkem:

  • Pokud používáte vývojové (testovací) techniky, měly by soukromé metody vzniknout pouze během procesu re-factoringu již fungujícího a testovaného kódu.

  • Samotnou povahou procesu bude jakýkoliv kousek jednoduché implementační funkce vyňaté z důkladně otestované funkce samočinně testován (tj. Nepřímé testování).

Zdá se mi dost jasné, že v první části kódování bude většina metod funkce vyšší úrovně, protože jsou zapouzdřující/popisující design.

Tyto metody budou proto veřejné a jejich testování bude snadné.

Soukromé metody přijdou později, až bude vše v pořádku a my budeme re factoringem kvůli čitelnosti a čistotě.

7
dkinzer

Jak bylo uvedeno výše, "Pokud nechcete otestovat své soukromé metody, jak víte, že se nezlomí?"

To je hlavní problém. Jedním z velkých bodů jednotkových testů je vědět, kde, kdy a jak něco přerušilo ASAP. Tím se snižuje značné množství vývoje a QA úsilí. Pokud je vše, co je testováno, veřejnost, pak nemáte čestné pokrytí a vymezení vnitřních částí třídy.

Našel jsem jeden z nejlepších způsobů, jak toho dosáhnout, je jednoduše přidat testovací odkaz na projekt a umístit testy do třídy paralelní se soukromými metodami. Umístěte vhodnou logiku sestavení tak, aby testy nezasahovaly do konečného projektu.

Pak máte všechny výhody testování těchto metod a můžete najít problémy v sekundách versus minuty nebo hodiny.

Takže v souhrnu ano, jednotka test vaše soukromé metody.

6
Adron

Neměl bys . Pokud mají vaše soukromé metody dostatek složitosti, kterou je třeba otestovat, měli byste je umístit do jiné třídy. Udržet vysoká soudržnost , třída by měla mít pouze jeden účel. Veřejné rozhraní třídy by mělo stačit.

5
fernandezdavid7

Pokud neotestujete své soukromé metody, jak víte, že se nezlomí?

4
Billy Jo

Je to samozřejmě závislé na jazyce. V minulosti jsem s c ++ prohlásil testovací třídu za třídu přátel. Bohužel to vyžaduje, aby váš výrobní kód věděl o testovací třídě.

2
dvorak

Chápu pohled, kde jsou soukromé metody považovány za detaily implementace a pak nemusí být testovány. A já bych se držel tohoto pravidla, kdybychom se museli vyvinout mimo objekt. Ale my, jsme nějakým omezeným vývojářům, kteří se vyvíjejí pouze mimo objekty a volají jen své veřejné metody? Nebo vlastně také vyvíjíme tento objekt? Vzhledem k tomu, že nejsme vázáni programovat vnější objekty, budeme pravděpodobně muset tyto soukromé metody nazvat novými veřejnými, které vyvíjíme. Nebylo by skvělé vědět, že soukromá metoda odolává všem šancím?

Vím, že někteří lidé by mohli odpovědět, že kdybychom do tohoto objektu vyvinuli jinou veřejnou metodu, pak by měla být testována a je to (soukromá metoda by mohla pokračovat bez testu). To však platí i pro všechny veřejné metody objektu: při vývoji webové aplikace jsou všechny veřejné metody objektu volány z kontrolních metod, a proto by mohly být považovány za implementační podrobnosti pro řadiče.

Proč tedy zkoušíme objekty? Vzhledem k tomu, že je opravdu těžké, nemožné říct, že testujeme metody regulátorů s příslušným vstupem, který spustí všechny větve základního kódu. Jinými slovy, čím vyšší jsme v zásobníku, tím obtížnější je otestovat veškeré chování. A to platí i pro soukromé metody.

Pro mě je hranice mezi soukromými a veřejnými metodami psychologickým kritériem, pokud jde o testy. Kritéria, která jsou pro mě důležitější, jsou: 

  • je metoda zvaná více než jednou z různých míst?
  • je metoda dostatečně sofistikovaná, aby vyžadovala testy?
2
Olivier Pichon

Pokud zjistím, že soukromá metoda je obrovská nebo složitá nebo dostatečně důležitá na to, aby vyžadovala vlastní testy, vložila jsem ji do jiné třídy a zveřejnila ji (Method Object). Pak můžu snadno otestovat dříve soukromou, ale nyní veřejnou metodu, která nyní žije ve své vlastní třídě.

1
Andy

Odpověď na "Mám testovat soukromé metody?" je někdy ".......". Typicky byste měli testovat na rozhraní svých tříd. 

  • Jedním z důvodů je to, že pro funkci nepotřebujete dvojité pokrytí. 
  • Dalším důvodem je, že pokud změníte soukromé metody, budete muset aktualizovat každý test pro ně, i když se rozhraní vašeho objektu vůbec nezměnilo.

Zde je příklad:

class Thing
  def some_string
    one + two
  end

  private 

  def one
    'aaaa'
  end

  def two
    'bbbb'
  end

end


class RefactoredThing
def some_string
    one + one_a + two + two_b
  end

  private 

  def one
    'aa'
  end

  def one_a
    'aa'
  end

  def two
    'bb'
  end

  def two_b
    'bb'
  end
end

V RefactoredThing máte nyní 5 testů, z nichž 2 jste museli aktualizovat pro refactoring, ale funkce vašeho objektu se opravdu nezměnila. Řekněme, že věci jsou složitější než ty a máte nějakou metodu, která definuje pořadí výstupu, například: 

def some_string_positioner
  if some case
  elsif other case
  elsif other case
  elsif other case
  else one more case
  end
end

To by nemělo být provozováno vnějším uživatelem, ale vaše zapouzdřující třída může být těžká na to, aby se tím mnoho logiky prošlo znovu a znovu. V tomto případě byste možná raději rozdělit toto do samostatné třídy, dát této třídě rozhraní a otestovat proti němu.

A konečně, řekněme, že váš hlavní objekt je super těžký a metoda je poměrně malá a opravdu potřebujete zajistit, aby výstup byl správný. Myslíte si: "Musím otestovat tuto soukromou metodu!". Máte možná, že můžete svůj objekt zesvětlit tím, že projdete některou těžkou prací jako inicializační parametr? Pak můžete předat něco lehčího a otestovat proti němu.

0
unflores

Nejde jen o veřejné či soukromé metody či funkce, ale o detaily implementace. Soukromé funkce jsou jen jedním z aspektů implementačních detailů.

Koneckonců, testování jednotek je bílý testovací přístup. Například, kdo používá analýzu pokrytí k identifikaci částí kódu, které byly do testování doposud zanedbány, jde do detailů implementace.

A) Ano, měli byste testovat podrobnosti implementace:

Přemýšlejte o třídicí funkci, která z důvodů výkonu používá privátní implementaci programu BubbleSort, pokud existuje až 10 prvků, a soukromá implementace jiného způsobu třídění (řekněme heapsort), pokud existuje více než 10 prvků. Veřejné rozhraní API je funkce třídění. Vaše testovací sada však lépe využívá znalostí, že ve skutečnosti existují dva třídicí algoritmy.

V tomto příkladu můžete určitě provádět testy na veřejném rozhraní API. To by však vyžadovalo mít několik testovacích případů, které provádějí třídicí funkci s více než 10 prvky, takže algoritmus heapsort je dostatečně dobře testován. Samotná existence takových testovacích případů je známkou toho, že testovací sada je spojena s prováděcími detaily funkce.

Změní-li se implementační detaily funkce třídění, možná způsobem, jakým je posun mezi dvěma třídícími algoritmy posunutý nebo že je heapsort nahrazen sloučením nebo cokoliv: Stávající testy budou pokračovat v práci. Jejich hodnota je nicméně sporná a pravděpodobně je třeba přepracovat, aby se lépe otestovala změněná funkce třídění. Jinými slovy, bude i nadále snaha o údržbu navzdory skutečnosti, že testy byly na veřejném rozhraní API.

B) Jak otestovat podrobnosti implementace

Jedním z důvodů, proč mnozí lidé argumentují, že by neměli testovat soukromé funkce nebo detaily implementace, je skutečnost, že podrobnosti implementace se s větší pravděpodobností změní. Tato vyšší pravděpodobnost změny přinejmenším je jedním z důvodů pro skrytí implementačních detailů za rozhraními.

Předpokládejme, že implementace za rozhraním obsahuje větší soukromé části, pro které by jednotlivé testy na vnitřním rozhraní mohly být volbou. Někteří lidé argumentují, že tyto části by neměly být testovány, pokud jsou soukromé, měly by se stát něčím veřejným. Jakmile bude veřejnost, bude testování jednotky v pořádku.

To je zajímavé: Zatímco rozhraní bylo interní, bylo pravděpodobné, že se změní, což je detail implementace. Vzít stejné rozhraní a učinit je veřejným nějakou magickou transformací, a to přeměnou na rozhraní, které je méně pravděpodobné, že se změní. V této argumentaci je zjevně chyba.

Nicméně je za tím nicméně pravda: Při testování implementačních detailů, zejména pomocí interních rozhraní, by se mělo usilovat o používání rozhraní, která budou pravděpodobně stabilní. Zda je určité rozhraní pravděpodobně stabilní, však není jednoduše rozhodnutelné na základě toho, zda je veřejné nebo soukromé. V projektech ze světa, na kterém jsem nějakou dobu pracoval, se často často mění i veřejná rozhraní a mnoho soukromých rozhraní zůstalo nedotčeno po celé věky.

Přesto je dobré použít „přední dveře jako první“ (viz http://xunitpatterns.com/Principles%20of%20Test%20Automation.html ). Ale mějte na paměti, že se nazývá "přední dveře první" a ne "pouze přední dveře".

C) Shrnutí

Otestujte také implementační detaily. Preferujte testování na stabilních rozhraních (veřejných nebo soukromých). Pokud se změní prováděcí podrobnosti, je třeba revidovat i testy veřejného API. Otočením něčeho soukromého na veřejnost se nezmění jeho stabilita.

0
Dirk Herrmann

Svou metodu můžete také nastavit jako soukromou, tj. Výchozí a měli byste být schopni ji otestovat, pokud není nutné, aby byla soukromá.

0
Techiee

Jeden hlavní bod je

Pokud testujeme, aby logika byla správná, a soukromá metoda má logiku, měli bychom ji otestovat. Není to? Tak proč to vynecháme?

Psaní testů založených na viditelnosti metod je zcela irelevantní. 

Naopak

Na druhou stranu je hlavním problémem volání privátní metody mimo původní třídu. A také existují omezení, aby se v některých zesměšňujících nástrojích zesměšňovala soukromá metoda. (Ex: Mockito)

I když existují některé nástroje, jako je Power Mock, které to podporuje, je to nebezpečný provoz. Důvodem je, že je třeba zasáhnout JVM, aby toho bylo dosaženo.

Jedna práce, kterou lze provést, je (Pokud chcete psát testovací případy pro soukromé metody)

Deklarovat tyto metody private jako protected. Ale nemusí to být vhodné pro několik situací.

0
Supun Wijerathne

Pokud je metoda dostatečně významná/složitá, obvykle ji „chráním“ a otestuji. Některé metody budou ponechány jako soukromé a testovány implicitně jako součást jednotkových testů pro veřejné/chráněné metody.

0
akapulko2020

Ano, pokud je to možné, měli byste testovat soukromé metody. Proč? Abychom se vyhnuli zbytečným exploze stavových prostorů testovacích případů, které nakonec nakonec jen implicitně testují stejné soukromé funkce opakovaně na stejných vstupech. Vysvětlíme, proč s příkladem.

Uvažujme o následujícím mírně kontroverzním příkladu. Předpokládejme, že chceme veřejně vystavit funkci, která vezme 3 celá čísla a vrátí hodnotu true pouze tehdy, pokud jsou všechna tři celá čísla prvočísla. Mohli bychom to implementovat takto:

public bool allPrime(int a, int b, int c)
{
  return andAll(isPrime(a), isPrime(b), isPrime(c))
}

private bool andAll(bool... boolArray)
{
  foreach (bool b in boolArray)
  {
    if(b == false) return false;
  }
  return true;
}

private bool isPrime(int x){
  //Implementation to go here. Sorry if you were expecting a prime sieve.
}

Kdybychom měli brát přísný přístup, že by měly být testovány pouze veřejné funkce, měli bychom pouze testovat allPrime a ne isPrime nebo andAll.

Jako tester bychom mohli mít zájem o pět možností pro každý argument: < 0, = 0, = 1, prime > 1, not prime > 1. Abychom byli důkladní, museli bychom také vidět, jak každá kombinace argumentů hraje společně. Takže to je 5*5*5 = 125 testovacích případů, které bychom museli důkladně otestovat tuto funkci podle našich intuic.

Na druhou stranu, kdybychom měli možnost otestovat soukromé funkce, mohli bychom pokrýt tolik důvodů s méně testovacími případy. Abychom otestovali isPrime na stejnou úroveň jako naše předchozí intuice, potřebovali bychom pouze 5 testovacích případů. A podle hypotézy malého rozsahu navrhovaného Danielem Jacksonem bychom museli testovat funkci andAll až na malou délku, např. 3 nebo 4. Který by byl nejvýše 16 dalších testů. Celkem tedy 21 testů. Namísto 125. Pravděpodobně bychom chtěli spustit málo testů na allPrime, ale necítili bychom se tak povinně podrobně pokrýt všech 125 kombinací vstupních scénářů, o kterých jsme říkali, že nám záleží. Jen pár šťastných cest.

Je to jistě příkladný příklad, ale bylo to nutné pro jasnou demonstraci. A vzor se vztahuje i na reálný software. Soukromé funkce jsou obvykle nejnižšími stavebními kameny a jsou tak často kombinovány dohromady, aby poskytovaly logiku vyšší úrovně. To znamená, že na vyšších úrovních máme více opakování věcí nižší úrovně díky různým kombinacím.

0
Colm Bhandal

Vidím, že mnoho lidí je ve stejné linii myšlení: test na veřejné úrovni. ale není to to, co dělá náš tým QA? Testují vstup a očekávaný výstup. Pokud jako vývojáři testujeme pouze veřejné metody, pak jsme jednoduše přepracovali práci QA a nepřidali žádnou hodnotu „testováním jednotek“. 

0
aemorales1

Veřejnost vs. soukromý není užitečným rozlišením pro to, co apis volá z vašich testů, ani není metoda versus třída. Většina testovatelných jednotek je viditelná v jednom kontextu, ale skrytá v jiných.

Důležité je pokrytí a náklady. Musíte minimalizovat náklady při dosahování cílů pokrytí vašeho projektu (řádek, větev, cesta, blok, metoda, třída, třída ekvivalence, případ použití ... Cokoliv).

Použijte proto nástroje, které zajistí pokrytí, a navrhněte své testy tak, aby způsobily nejméně nákladů (krátkodobé i dlouhodobé). Někdy můžete snadno získat veškeré pokrytí, které potřebujete, testováním pouze hlavního vstupního bodu celé aplikace. Častěji snížíte náklady na dosažení pokrytí testováním na různých vnitřních vstupních místech. Tento koncept se nezastaví při viditelnosti metody.

Často dobrý design modulu dělá to nejlevnější spustit test proti vstupním bodům deklarovaným veřejným, ale to není zaručeno.

Nezáleží na soukromém vs. veřejném.

Neprovádějte testy dražšími testováním všech soukromých metod a nedělejte testy dražší tím, že se vyhnete přímým voláním některých metod.

0
tkruse

Ne Neměli byste testovat soukromé metody proč? a navíc populární zesměšňovací rámec jako Mockito neposkytuje podporu pro testování soukromých metod.

0
cammando

Nikdy jsem nepochopil pojem Unit Test, ale teď vím, co je cílem.

Jednotkový test není úplný test . Takže to není náhrada za QA a manuální test. Koncept TDD v tomto aspektu je špatný, protože nemůžete otestovat vše, včetně soukromých metod, ale také metod, které využívají zdroje (zejména zdroje, které nemáme pod kontrolou). TDD vychází ze své kvality a je to něco, čeho nelze dosáhnout.

Test jednotky je více a pivot test Označíte nějaký libovolný pivot a výsledek pivotu by měl zůstat stejný. 

0
magallanes