Honsal's Dailylife

반복되는 마무리 처리 오늘, 단위 테스트를 진행하다가 난감한 상황을 맞닥뜨렸습니다. 단위 테스트 대상 메서드는 ADB를 통해 특정 작업을 시행한 뒤 Redirect된 출력을 바탕으로 내용을 분석해 원하는 결과가 나왔는지 체크하는 메서드였는데요. 문제는, ADB 프로세스를 처음 실행할 때, 데몬 모드로 프로세스가 꺼지지 않게 계속 실행된다는 것 입니다. 이 문제를 해결하기 위해서, 여러 시도를 했습니다. 우선, 매 adb 명령이 완료될 때마다 프로세스 리스트에서 adb를 모두 종료하는 방식이 첫번째였죠. 하지만, 이 경우에 ADB 작업이 실행될 때마다 데몬이 켜지길 반복 하기 때문에, 심각할 정도의 CPU 자원 낭비 , 즉 딜레이 가 생겼습니다. 그래서, ADB 관련 처리를 하는 클래스에 IDisposable 을 구현한 뒤, Dispose() 메서드에서 전체 adb 프로세스를 죽이는 작업을 처리하도록 했습니다. 이러면 아래와 같이 사용할 수 있죠. using ( var manager = new AdbManager()) { // TODO: Process... } 실사용에선 별 문제가 없어 보입니다. 그렇지만, 고작 단위 테스트 하나를 위해서 저렇게 해야될까요? 당연히 아닙니다. 제가 사용하는 NUnit 테스트 프레임워크엔 이럴 경우를 위한 어트리뷰트가 마련돼 있습니다. 물론, 다른 프레임워크도 비슷한 기능이 있으나, 이번에 제가 포스팅할 것은 제가 사용하는 NUnit에 대해서입니다. SetUpAttribute, TearDownAttribute 바로 SetUpAttribute 와 TearDownAttribute 입니다. 각각 단위 테스트를 시작하기 전, 그리고 단위 테스트를 마친 후 시행될 작업을 정의할 메서드에 붙여주시면 됩니다. 지금 제 상황에 맞게 코딩해볼까요? [TestFixture] public class AdbManagerTests { // 다른 수많은 비슷한 테스트 메서드들... [

디버그의 필수요소. 이 라인까지 실행 후 BREAK   디버그를 하다 보면 break포인트만으로는 감당할 수 없는 상황이 자주 생깁니다. 예를 들어 다음과 같은 코드가 있다고 생각해보세요. if (elemMore != null ) { Log.InfoFormat( "어떠어떠한 로그를 출력!" ); CurrentPage.Click(elemMore); CurrentPage.WaitForNetworkIdle0( 30000 ); if (_isPageTabNewWindowCreated == false ) GoBackCount++; }   이제 디버그를 돌립니다. 첫줄의 if문에 breakpoint를 걸고, 다음과 같은 프로세스를 따르고자 합니다. elemMore이 null인지 체크 null이 아니어야 함. elemMore가 제대로 스크롤된 후 클릭되는지 확인. _isPageTabNewWindowCreated가 true로 변경되었는지 확인.   자, 여기서 가장 효율적인 디버깅 방법은 뭘까요? 언뜻 생각해서는, 추가로 Click 메서드에 breakpoint를 걸고, WaitForNetworkIdle0에도 걸고, 그 밑의 if문에도 걸고… 그리고 실행한 뒤 F5를 눌러가며 breakpoint를 따라 디버깅하는 방법이 최선이라 생각할 수도 있습니다.   그러나 Visual Studio에서는 그러한 노가다를 방지하기 위한 효과적인 방법을 제시해줍니다. 바로 ‘현재 커서까지 실행’ 이라는 기능이죠. 이 기능을 사용하면, 현재 커서(마우스 커서가 아닙니다. Character 커서입니다.)까지 실행한 뒤 알아서 중지됩니다.   그럼, 어떻게 써야할까요? 커서까지 실행   위의 초록색 재생 버튼이 보이시나요? 디버그 중 breakpoint에 걸린 상태에서, 즉 일시 중지된 상태에서 특정 라인에 마우스를 올려두면 저렇게 초록색 여기까지 실행 버튼이 나타나게 됩니다. 그

최신기술을 맹신하다가 프로젝트 한 개가 통채로 날아가게 된 사건 바로 오늘 있던 일입니다. 최근 두 달간 3년 가까이 진행되어온 프로젝트의 마무리 및 약간의 보수 작업을 해왔습니다. 핵심 라이브러리를 다른 라이브러리로 대체하는 작업이었죠. 기존 프로젝트가 여러 사람이 달라붙어서 작업한다는 전제가 없었기 때문에, 주석도 완벽하지 않고 프로젝트 구조 파악도 어려워 기존 라이브러리를 사용하는 클래스들을 수정하는 것이 아닌, 기존 클래스명에 특정 접두사를 붙여 다른 네임스페이스에 새로운 라이브러리를 사용해 같은 프로세스를 진행하는 클래스를 만들게 되었습니다. 이를 위해, 우선 기존 클래스의 본문을 복사해 접두사가 붙은 새로운 클래스의 본문에 붙여넣고 , 기존 라이브러리에서 새로운 라이브러리로 대체되는 부분만 수정 하는 작업을 진행했죠. 물론, 기존 라이브러리에서 지원하지 않거나 새로운 라이브러리에서 지원하지 않는 부분은 추가/제거 작업을 병행했습니다. 숨겨진 양날검: ReSharper Code Cleanup 그런데 이렇게 하고 보니 코드가 영 보기 좋지 않았습니다. 처음부터 클래스를 작성했으면 모를까, 이미 붙여넣어진 수천줄의 코드에서 뺄 부분을 빼고 추가할 부분을 추가하고 수정할 부분을 수정하다 보니 개행도 엉망진창, 들여쓰기도 엉망진창, 급했던 부분에선 띄어쓰기도 엉망진창인 상태 가 되었습니다. 하지만 이러면 어떠하고 저러면 어떠하리, 저에겐 사랑스런 ReSharper가 있었고, 여기엔 VS 기본 코드 클린업과는 비교도 되지 않는 강력한 클린업 기능이 있습니다. 단순 줄 정리, 들여쓰기 정리는 물론, auto property로 만들 수 있는 프로퍼티는 auto property로 자동으로 만들어주고, 람다 메서드로 만들 수 있는 부분은 람다 메서드로 만들어주고, 읽기 전용으로 만들 수 있는 필드는 읽기 전용으로, 오토 프로퍼티 중 get만 사용할 수 있는 프로퍼티는 get만 남기고, String, Boolean등을 자동