Java testy jednostkowe, układ katalogów

Zalecam stosowanie się do standardowej struktury katalogów Apache Software Foundation , co daje:

module/
  src/
    main/
      java/
    test/
      java/

To utrzymuje testy oddzielnie od źródła, ale na tym samym poziomie w strukturze katalogów. Jeśli przeczytasz, w jaki sposób Apache definiuje ich strukturę, zobaczysz, że pomaga również dzielić inne problemy, w tym zasoby, pliki konfiguracyjne, inne języki itp.

Ta struktura umożliwia również testy jednostkowe do testowania metod poziomu pakietu i chronionego jednostki testowane, zakładając, że umieścisz swoje przypadki testowe w tym samym opakowaniu, co to, co testują. Jeśli chodzi o testowanie prywatnych metod - nie zawracałbym sobie głowy. Coś innego, publiczne, pakietowe lub chronione wywołuje je i powinieneś być w stanie uzyskać pełny zasięg testowania tych rzeczy.

Nawiasem mówiąc, powyższy link jest do Maven, standardowego narzędzia do budowania Apache ' a. Każdy projekt Java jest zgodny z tym standardem, jak również każdy napotkany przeze mnie projekt Zbudowany z Maven.

Większość razy robi się tak:

<SOME_DIR>/project/src/com/foo/Application.java
<SOME_DIR>/project/test/com/foo/ApplicationTest.java

Tak więc, zachowujesz je osobno i nadal możesz przetestować pakiet / chronioną funkcjonalność, ponieważ test znajduje się w tym samym pakiecie.

Nie możesz testować prywatnych rzeczy, chyba że zostaną zadeklarowane wewnątrz klasy it self.

Po dostarczeniu wystarczy spakować .class wygenerowane przez src, a nie testy

Właściwie to ma sens rozdzielenie projektów produkcyjnych i testowych na dwa oddzielne podmioty, ale mają taką samą strukturę pakietów w obu projektach.

Więc jeśli mam projekt 'mój-projekt' to również tworzę 'mój-projekt-test', więc mam następującą strukturę katalogów:

my-project
  +--- src/com/foo
my-project-test
  +---test/com/foo

Takie podejście zapewnia, że zależności kodu testowego nie zanieczyszczają kodu produkcyjnego.

Moim zdaniem Pakiety prywatne i chronione powinny być testowane jak i publiczne metody. Dlatego chcę, aby moje zajęcia testowe były w tym samym pakiecie, co zajęcia produkcyjne.

Tak to ustawiamy i lubimy.

build/
src/
test/build/
test/src/

Cały kod testowy kompiluje się do własnego katalogu kompilacji. Dzieje się tak, ponieważ nie chcemy, aby produkcja przez pomyłkę zawierała klasy testowe.

Podczas tworzenia biblioteki Java moduł w Android Studio tworzy domyślną klasę Pod:

[module]
   + src/main/java/[com/foo/bar]

Jeśli zajrzysz do pliku [module].iml, znajdziesz tę ścieżkę, jak również ścieżkę do testów, którą możesz wykorzystać. Poniżej znajduje się podsumowanie:

<module>
  <component>
    <content>
      <sourceFolder url="file://$MODULE_DIR$/src/main/java" isTestSource="false" />
      <sourceFolder url="file://$MODULE_DIR$/src/main/resources" type="java-resource" />
      <sourceFolder url="file://$MODULE_DIR$/src/test/java" isTestSource="true" />
      <sourceFolder url="file://$MODULE_DIR$/src/test/resources" type="java-test-resource" />
    </content>
  </component>
</module>

Możesz w szczególności utworzyć katalog testów o następującej strukturze:

[module]
   + src/main/java/[com/foo/bar]
   + src/test/java/[com/foo/bar]

Powyższa struktura zostanie rozpoznana przez Android Studio , a Twoje pliki pod spodem będą zawarte w module.

Zakładam, że ta struktura jest zalecanym układem dla kodu i testów.