-검증대상의 행위가 실제 앱에서 동작할 것으로 기대되는 행위와 일치해야 한다.
-원래 설계하고자 하는 행위가 설계를 통해서 정확하게 표시된다고 하는 의미에서 정확성이 중요한것이다.
-명확성은 간결성과 완결성 두가지로 나뉜다.
-안전성은 연관되지 않는 변경사항에 대한 안전성 또는 탄력성을 의미한다.
-실제의 동작이 테스트에 반영이 되어서 실제로 도움이 되는 방향으로 개발이 되어야 한다. 그래서 실제 동작이 실제로 실패하면 테스트도 실제로 실패해야 되는 것이고 실제 동작이 실제로 성공하면 테스트도 실제로 성공해야 한다.
-테스트의 설정오류 또는 테스트를 실수로 잘 못 만들었다 등의 여러 이유로 인해서 테스트이 결과가 실패로 나오는 경우가 특정 확률에 기반으로 해서 발생한다면 안된다.
-1. 의존성이 있다면 가능한 실제 코드를 사용해서 테스트하도록 되어있다.
-2. network 등의 실행 속도가 느린 API의 경우 또는 외부에 의존성이 발생하는 경우 fake를 구현하면 된다.
-3. 위의 두가지 방법으로 테스트하는 것이 불가능한 상황에서만 mock으로 테스트한다. mock 사용시 주의할 점은 의존성이 큰 코드이거나 외부 시스템을 사용해야 할 때 같은 경우는 가급적 사용을 지양하는 것이 좋다.
-느린 테스트 시간을 절약하기 위해서 가능한 많은 내용이 담긴 큰 테스트 케이스를 작성하는 것은 지양해야 한다. 예를들면 메서드를 테스트 할 때 메서드에 여러 가지 기능들이 있을텐데 그것들을 하나로 묶어서 묶인 메서드를 테스트하는 테스트 케이스를 하나 만들어서 성공했을 때 성공의 조건을 여러가지로 넣는 경우가 있다. 이런 경우는 테스트의 속도는 빠를지 몰라도 유지 보수가 굉장히 어려운 테스트코드가 되기 때문에 지양해야 한다. 왜냐하면 하나의 테스트가 많은 부분 부분들을 테스트하고 있기 때문이다. 만약, 여러개의 요소들 중에서 단 하나의 요소로 인해서 테스트가 실패했을 때 무엇때문에 테스트가 실패했는지 알 수 가 없다.
-view를 위한 테스트를 구현하지 않는것은 지양해야 한다. 그러나 많이 구현할 필요는 없는데 왜냐면 view를 위한 테스트는 일반적으로 의존성이 안드로이드 플랫폼에 대해서 생기기 때문에 특히, Context에 대한 의존성이 있기 때문에 구현하기 벅업다.. 하지만 핵심적인 부분에서 특정 뷰 컴포넌트라든가 그런 것들이 입력이 들어왔을 때 어떻게 출력되는지 하는 것들은 구현할 필요가 있다.
-앱의 crash를 막기위해 테스트를 추가하는 것보다 그냥 catch를 통해서 에러를 무시하는 것은 지양해야 한다.