테스트 구현 (2) - 앱 안정성 및 확장성 강화를 위한 Android 아키텍처(4)

 

예시

 

 

 

 

=> isVaild 를 테스트 하게되면  isVaild는 프라이빗이기 때문에,, public으로 바꾸지 않아야 한다. 

=> isVaild 정책의 변경에 따라 저 코드는 문제가 될수 있다. 

 

 

 

=> set ,  process , assert 하는 구조는 앞으로도 계속 되는 구조임으로 기억하자.

=> 트렌젝션을 직접 만들어서 처리를 해보는 것이 좋다. 

 

 

---

 

=> 테스트를 통해서 나올 결과를 가지고 판단을 해야하지, 나온 결과를 또다른 조작을 통해서 판단 검증해서는 안된다.

=> 위에 예시에서는  createUser로 만든 계정을 아래서  db에 넣음으로써 검증을 하는 또다른 조작을 하고 있다.

 

---

 

완결성 : 테스트는 전부를 가지고 있어야한다, 완성되어있어야 한다. 

=> 그 테스트케이스 안에는 테스트하고자 하는 것을 정확일 알수 있도록 정보를 포함 하고 있어야 한다.

=> 어떤 조건으로 이함수를 실행하면 이렇게 나온다. 라는걸 정확히 알수 있어야 한다.

 

간결성  : 테스트에 관련된 정보만 가지고 와야한다.

예를 들어 20개 파라미터중 5개만 필요하다면 15개는 숨겨야 한다.

또 5개가 변경되었을때를 테스트 하는것이기 때문에 15개는 변경해도 문제가 발생하면 안된다.

 

=> 알수없는 파라미터들이 무엇을 의미하는지 알수 없기때문에 좋은것이 아니다.  

 

 

---

=> 테스트케이스는 메소드를 테스트하는게 아니라 기능을 테스트를 하는거다. 

=>  행위  :  메소드 = 1 : N 

=>  예를 들어 연관성 없는 validation 같은경우는 안티 패턴이다.

 

=> 하나의 메소드에서 두개의 결과를 같이 테스트해버리는 결과가 나왔다

=> 테스트 네이밍도 이상하다. 

=> 행위가 두개가 들어간거다 . 

 

=> 메소드 이름 부터 마음에 든다. 

=> 테스트 케이스당 행위는 하나다. 

=> 위 아래  컨디션이 다르다.  분리를 잘 한거다.

 

---

 => 세 단계가 명확히 구분되어있는 것이 좋다. 

=> 두가지 기능이 모두다 만족되어야 하는 행위 ( 행위는 1개 이다 )

=> 완결성이 담보되었다

 

---

=> BaseURL 부분을 그냥 하드코딩하는 편이 좋다 . ( 실수 방지 )

 

---

=> 서로 상충되는 경우가 있다면 DAMP 가 우선되어야 한다.

=> 더좋은 확실하고, 유의미한 테스트가 만들어진다면 어느정도 방법은 용인된다.

=> 어떤 조건이 유저 크리에이트가 가능한지 알수 없다 ( 가독성이 좋지 않다) 확인하려면  크리에이트 유저스를 타고 들어가야한다.

 

=> 중복은 되지만, 이 테스트케이스가 명확해 진다.

---

 

 

=> 파일내에 있는 private이기때문에 공용변수가 되어 테스트 할때 사용된다.

=> 테스트 케이스만 보고 알수 없다.

=> 잔고가 변경된경우, 다른 케이스에도 영향을 줄수 있다.

---

 

=> user1 이라는 것을 아래의 테스트케이스에서도 값을 알고 있어야 한다는 문제가 있다. 

=> 하고있는 일이 명확하다 

=> assetthat이 덕지 덕지 붙어있는 건 안좋은거다.

 

---