본문 바로가기
[Effective Unit Testing] Chap7. 테스트 가능 설계 [Effective Unit Testing] Chap7. 테스트 가능 설계 7.1. 테스트 가능 설계란? -테스트 가능 설계의 가장 큰 의의는 당연히 코드를 더 잘 테스트할 수 있도록 해준다는 것이다. -테스트 용이성(testability)이란 테스트할 수 있는 소프트웨어냐 아니냐를 설명하는 용어가 아니다.그보다는 소프트웨어를 멀마나 쉽게 테스트할 수 있느냐를 평가하는 용어다.단위 테스트를 위한 시나리오 준비는 식은 죽 먹기여야 한다.테스트 용이성이 떨어질수록 테스트를 작성하는 프로그래머의 부담이 커진다. 7.1.1. 모듈러 설계 -제품은 특정 역할을 담당하는 독립 모듈로 구성된다는 그 본질만 잘 반영하면 자연스럽게 모듈러 설계가 만들어진다.제품의 전체 기능을 뚜렷한 역할로 나누고 그 역할 각각을 독립된.. 2019. 3. 17.
[Effective Unit Testing] Chap6. 신뢰성 [Effective Unit Testing] Chap6. 신뢰성 -테스트를 작성하는 이유이기도 한 신뢰할 수 있는 코드를 만들기 위해서는 테스트 자체도 믿음직해야 한다.소프트웨어 개발에는 코드를 수정하고 개선하고 관리하는 일이 빠질 수 없는데, 만약 테스트를 믿지 못한다면 아무 관련 없어 보이는 코드라도 쉽사리 바꾸지 못한다. -주석은 이해를 돕기 위한 설명글로 코드에 적어 넣을 수 있다는 요긴함이 있지만,자칫 한눈파는 순간 엉터리 정보로 둔갑하는가하면, 본문 전체를 주석 처리한 테스트는 실제로는 아무것도 안 하면서 성공했다고 보고되기도 한다. 6.1. 주석으로 변한 테스트 -주석으로 변한 테스트(Commented-out Test)는 아무런 설명도 없이 읽는 이에게 혼란을 가져다 준다. 6.1.1. 예시.. 2019. 3. 15.
[Effective Unit Testing] Chap5. 유지보수성 [Effective Unit Testing] Chap5. 유지보수성 -코드는 쓰이는 횟수보다 읽히는 횟수가 훨씬 많다.그리고 현실에서의 작성의 대부분은 기존 코드를 수정하거나 확장하는 걸 뜻한다.이를 유지보수라 하기도 하고 개발이라 부르기도 한다. -테스트도 태생은 제품 코드와 다를 바 없는 코드인지라, 근본적으로 똑같이 불안정하다.자동화된 단위 테스트를 작성할 때도 이런 취약성에 주의하면서 관리해야 한다. 5.1. 중복-모든 악의 근원 넘버원은 “어설픈 최적화” 이고, 넘버투는 “중복(Duplication)이다. 5.1.1. 예시 -상수 중복은 given 과 then 의 상수를 따로 정의해서 쓰는 것을 이야기한다.상수 중복은 지역 변수로 만들어서 제거할 수 있다. 5.1.2. 개선 방법 -구조 중복과 .. 2019. 3. 14.
[Effective Unit Testing] Chap4. 가독성 [Effective Unit Testing] Chap4. 가독성 -테스트를 읽은 프로그래머는 코드가 “해야 할 일”을 이해할 수 있어야 한다.또한, 테스트를 실행한 후에는 코드가 실제로 "한 일”이 무엇인지 말할 수 있어야 한다. -테스트의 핵심인 단언문은 대상 코드의 올바른 동작을 규정한다. -결국, 테스트 코드는 읽기 쉬워야 한다.테스트가 무슨 일을 하는지 파악하기 위해 머리를 쥐어뜯는 일은 없어야 한다. -테스트 냄새는 숱하게 많지만, 그중에서도 가장 흔한 냄새는 바로 "기본 타입 단언”이다. 4.1. 기본 타입 단언 -단언문은 가정이나 의도를 명시해야 한다.또한 코드의 동작을 서술하는 문장이어야 한다.기본 타입 단언(Primitive Assertion)이란 단언하려는 이유나 의도가 의미를 알 수 .. 2019. 3. 13.
[Effective Unit Testing] Chap2. 좋은 테스트란? [Effective Unit Testing] Chap2. 좋은 테스트란? -좋은 테스트의 고려 사항은 아래와 같다. 테스트 코드의 가독성과 유지보수성 프로젝트 안에서, 그리고 소스 파일 안에서 코드는 적절히 구조화되어 있는가? 테스트가 무엇을 검사하는가? 테스트는 안정적이고 반복 가능한가? 테스트가 테스트 더블을 잘 활용하는가? ... 2.1. 읽기 쉬운 코드가 유지보수도 쉽다.-자동화된 테스트는 결함을 효과적으로 막아주지만, 테스트 역시 코드인지라 가독성 문제에서 벗어날 수는 없다.읽기 어려운 코드는 검증하기도 어렵고, 결과적으로 테스트를 조금만 작성하는 사태로까지 이어진다.또 그렇게 작성된 테스트는 우리가 생각하는 좋은 테스트와는 거리가 멀다.제품의 구조와 API 가 테스트를 고려하지 않고 만들어졌다.. 2019. 2. 27.
[android] Mockito 맛보기 ( test library ) https://www.tutorialspoint.com/mockito/mockito_overview.htm http://www.vogella.com/tutorials/Mockito/article.html https://static.javadoc.io/org.mockito/mockito-core/2.12.0/org/mockito/Mockito.html#mockito - Mockito 는 JUnit 위에서 동작하며 Mocking 과 Verification, Stubbing 을 도와주는 프레임워크이다. ( 이 자체가 testing 하는 framework 는 아니다!! ) Mockito 를 사용하면 Mock 을 만들어서 external dependency 를 제거할 수 있고, code 가 제대로 수행하는지 검증.. 2018. 12. 7.
[Kotlin Tutorial] The Kotlin ecosystem [Kotlin Tutorial] The Kotlin ecosystem 참조 : Kotlin in action -비록 Kotlin 의 역사는 오래되지 않았지만, 이미 lib, framework, tool 들로 구성된 ecosystem 이 잘 마련되었다.그리고 그들은 대부분 외부 개발 커뮤니티에서 개발된 것이다. https://kotlin.link/ 여기 가면 많은 정보를 얻을 수 있다. -Kotlin 은 Java 와 함께 사용가능하기 떄문에,lib 검색할 떄 Kotlin lib 으로 한정지을 필요가 없다. 당연히 Java lib 을 가져다 써도 된다. 1. Testing -JUnit, TestNG 도 좋지만, 아래 DSL 들은 더 표현력이 풍부하다. KotlinTest https://github.com/k.. 2017. 9. 22.
[Effective Java] 작명 패턴보다는 주석(annotation)을 사용하자. [Effective Java] 작명 패턴보다는 주석(annotation)을 사용하자. - 1.5 배포판 이전에는 도구나 프레임워크에서 특별히 취급할 필요가 있는 프로그램 요소들을 나타내기 위해 작명 패턴(naming pattern)을 사용하는 것이 일반적. 예를 들어 JUnit 테스팅 프레임워크에서는 테스트 메소드들의 이름을 test로 시작하도록 하였다. 이 방법은 효과는 있지만 단점들이 있다. 1. 철자상의 오류로 인한 오류 2. 적합한 프로그램 요소에만 사용되는지 확신할 방법이 없다. 3. 매개 변수 값을 프로그램 요소와 연관시키는 좋은 방법을 제공하지 않는다. - 작명패턴의 단점은 annotation 을 사용하여 깔끔히 해결된다. - annotation 정의는 다음과 같이 한다. @Retention.. 2017. 1. 2.
[android] CodePro Analytix 내 코드를 분석하자. 안드로이드, CodePro Analytix 내 코드를 분석해보자. https://developers.google.com/java-dev-tools/codepro/doc/?hl=ko&csw=1 CodePro Analytix는 이클립스 개발자를 위한 Java 테스팅 및 코드 분석 툴이다.개발자들이 보다 훌륭한 품질의 코드를 작성하도록 도와주며, 오류를 줄이는 데도 도움을 준다. 이전에는 상용이었는데, 구글이 인수한 후 무료로 기부 배포!! CodePro Analytics 로 할 수 있는 일들. 1. 코드 분석 ( Code Analysis )2. 코드 지표 측정 ( Metrics )3. 유사 코드 분석 ( Similar Code Analysis )4. 코드 커버리지 측정 ( Code Coverage )5. 코.. 2014. 1. 9.
반응형