TDD

프롤로그 요즘 IDE 또는 그 확장 솔루션들 예를들어 SonarLint 등이 아주 아주 성능이 좋아져서 중복된 코드나 복잡도가 높은 코드를 발견하면 잔소리를 늘어 놓는다. 사람이 하는 잔소리라면 한번 듣고 넘어가겠지만 계속 노란줄로 너 이거 “계속 안고칠꺼야?” 하고 경고를 한다. 테스트를 작성하다 보면 흐름은 거의 비슷하고 데이터 만 바뀌고 여기에 따라서 단정문도 살짝 바뀌는 수준의 테스트 메서드를 여러개 작성하게 된다. 이 경우 요즘 정적 분석기는 이런 중복도 잡아 준다. 뭐 정적 분석기가 잔소리를 하던 말던 제품 코드 뿐만 아니라 테스트 코드도 중복되어 좋을 것이 없다. 오늘은 이 문제를 해결하기 위한 방법을 하나 소개한다. Parameterized test 궂이 우리 말로 번역하자면 인자화 테스트..

결론부터 말하면 아래 어트리뷰트를 설명하려고 한다. 닷넷 어셈블리를 구현을 할 때 이와 대응되는 테스트 프로젝트를 별도로 작성하게 된다. 근데 우리가 테스트 하려는 대상의 접근 한정자가 internal이면 어쩌지 테스트를 하려고 public으로 바꿔야 하나? 나만의 고민이 아니였고 이미 해법은 있었다. 보통 나는 구현하려는 어셈블리가 "OOO"이라는 이름을 갖게 되면 테스트는 "OOO.Test"라고 명명을 한다. 다른 분들도 그렇게 보통 하는 듯 하다. 아래 어트리뷰는 즉 "OOO"어셈블리의 AssemblyInfo.cs에 지정하는 것이다. "OOO.Test"에게 나의 Internal을 보여줘!!! [assembly: InternalsVisibleTo("OOO.Test")]