Nazewnictwo testów

0

Hej, czy prefereujecie jakąś konwencję nazewnictwa testów? Czy popularnym i akceptowalnym podejściem jest inna konwencja dla testów jednostkowych i integracyjnych ?

Ja w 95% przypadkach spotykam się wszędzie z should...

Co sądzicie o konwencji w stylu addUser_lastNameIsTooLong_nameTooLongExceptionIsThrown

2

Jakby używać języka i frameworka który pozwala na zagłębianie testów jak RSpec lub Specs2 to problem sam się rozwiązuje. Przykład w Specs2

class MySpecification extends org.specs2.mutable.Specification {
  "this is my specification" >> {
    "where example 1 must be true" >> {
      1 must_== 1
    }
    "where example 2 must be true" >> {
      2 must_== 2
    }
  }
}
0

wygląda jak konwencja z projektu z poprzedniej mojej firmy. Jestem za, podłogi "_" ułatwiają czytanie

0

@KamilAdam

A gdy masz tylko jave i junit?

0

To starałbym się rzeczy podobne trzymać na początku nazwy a rzeczy zmienne na końcu nazwy.
Czyli methodName_StateUnderTest_expectedBehavior, czyli to co podałeś

1

@Bambo:

A gdy masz tylko jave i junit?

To płaczę.

Wpięcie kotlina na testy (kotest) czy Spocka - to jedna z łatwiejszych do przewalczenia rzeczy (z korpoarchitektami),
a zysk duży.

2
Bambo napisał(a):

A gdy masz tylko jave i junit?

To robię klasy zagnieżdżone. Wtedy nazwa klasy jest moim "methodName", a potem każdy test ma "conditions_expectedLogicalOutcome".

4

Ja się coraz bardziej przekonuje do @DisplayName w Junit5

@DisplayName("Throws ArithmeticException when dummy user tried to divide by 0")
void test1() {

}
2

Co prawda z działki .net, ale ogólne założenia powinny być identyczne:

Wprowadzenie dodatkowych, wewnętrznych klas pozwala wyjąć nazwę testowanej metody z - i tak długiej - nazwy testu oraz pozwala testy logicznie pogrupować.

1 użytkowników online, w tym zalogowanych: 0, gości: 1