14장. 프로젝트에서 테스트. 빠른 도입 단위테스트와 같은 실천법을 배우는 것은 끊임없는 경계를 요구한다. 팀원들과의 마찰이 생길 수도 있는데 아마 팀원은 조심스럽지 않게 테스트 코드보다 훨씬 빨리 코드를 만드는 것에 집중할 것이다. 처음부터 품질을 통제하면서 개발하길 주장하면 코드가 엉망이 되는 것을 최소한으로 줄일 수 있다. 이러한 단위 테스트가 팀 문화의 습관적인 일부가 될 수 있을지 토론해보는 것도 좋다. 팀과 같은 편 되기 아래 두 질문에 대한 대답을 생각하면서 단위 테스트 표준을 만들자. 개발자들은 어떤 것이 모든 사람의 시간을 많이 낭비하게 만든다고 느끼는지? 모두가 빠르게 동의할 수 있는 표준은 무엇인가? 초창기에 표준화해야 하는 목록은 아래와 같다. 코드를 체크인하기 전에 어떤 테스트를 ..

에디터의 개요 리눅스에서 지원하는 편집기로는 vi, emacs, pico 등이 있음. 원래 파일은 훼손되지 않게 남겨두고 해당 파일의 복사판을 만들어 임시 기억장치에 둠. 임시 기억 장치는 편집기의 버퍼 역할을 함. 단점은 외부적인 원인으로 갑자기 편집기가 종료되었을 경우 변환된 내용을 모두 잃게 된다는 것. 에디터의 종류 Pico 유닉스 기반의 텍스트 에디터. 메뉴 선택 방식의 텍스트 편집기로 기본 인터페이스가 윈도우의 메모장과 유사. 자유 소프트웨어 라이선스가 아니기 때문에 소스 수정이 불가능. 입력 모드와 명령 모드가 존재하지 않고 바로 텍스트 입력이 가능. Emacs 리처드 스톨만이 매크로 기능이 있는 텍스트 교정 및 편집기로 개발. LISP에 기반을 둔 환경 설정 언어를 가지고 있음. 단순 편집..

프로세스의 개념 프로세스는 CPU와 메모리를 할당받아 실행시키는 프로그램.(= 실행 중인 프로그램) 프로세스마다 고유의 프로세스 ID인 PID를 할당 받음. 프로세스 init에 의해 다른 모든 프로세스들이 시작. 포그라운드 프로세스와 백그라운드 프로세스 포그라운드 프로세스(Foreground) 사용자와 상호작용하는 프로세스. 터미널에 직접 연결되어 입출력을 주고받는 프로세스. 명령 입력 후 수행 종료까지 기다려야 하는 프로세스. 화면에서 실행되는 것이 보이는 프로세스. 백그라운드 프로세스(Background) 사용자와 직접적인 대화를 하지 않고 뒤에서 실행되는 프로세스. 사용자의 입력에 관계없이 실행되는 프로세스. 실행은 되지만 화면에 나타나지 않고 실행되는 프로세스. fork()와 exec() fork..

셸이란? 명령어 해석기로 커널과 사용자 간의 대화식 인터페이스를 제공. 로그인할 때 실행되어 사용자별로 사용 환경 설정을 가능하게 함. 강력한 스크립트 언어로 입출력 방향 재지정가 파이프 기능을 제공. 포그라운드/백그라운드 프로세스를 실행. 셀의 종류 본셸계열과 C셸 계열로 나뉨. 사용자 프롬프트가 $이면 본셸계열, %면 C셸 계열을 사용하고 있다는 것. 대부분의 셸은 본셸 계열의 기능을 포함하여 확대 발전한 형태. 셸 확인 및 변경 사용자가 로그인 후 자동으로 생성되는 로그인 셸과 사용자가 직접 변경하는 서브 셸로 구분. 명령어 'echo $SHELL'로 현재 로그인한 사용자가 사용하고 있는 셸 확인 가능. 로그인 셸 변경은 반영구적인 셸 변경 방법으로 관리자가 셸 변경 후 다음 변경을 하기 전까지 지..

리눅스 시스템의 모든 파일과 디렉터리에는 접근 권한과 소유권이 부여됨. 명령어 ls -l은 파일 속성을 나타냄. 파일 속성의 첫 번째 필드는 파일이나 디렉터리의 허가권, 세 번째와 네 번째 필드는 파일이나 디렉터리 소유권 나타냄. 소유권(Ownership)과 관련된 명령어 소유권은 임의의 파일 또는 디렉터리에 대해 사용자와 그룹들의 소유 권한을 나타낸 것. 그룹은 사용자들의 시스템 운영 특성에 따라 묶어 놓은 것으로 같은 그룹에 속한 사용자들은 동일 소유권을 가짐. chown - 파일과 디렉터리의 사용자 소유권과 그룹 소유권을 변경. chgrp - change group을 줄인 명령어로 파일이나 디렉터리의 그룹 소유권을 변경. 옵션 -R로 하위 디렉터리를 포함하여 디렉터리 내부의 모든 파일의 그룹 소유권..

13장. 까다로운 테스트. 어떤 코드는 테스트하기 까다로운 코드들이 존재한다. 특히 스레드와 영속성에 연관된 코드를 테스트하는 것이 까다롭다. 이 장에서는 스레드와 영속성을 테스트하는접근 방법 두 가지 주제에 기반을 두어 어떻게 하는지 살펴본다. 멀티스레드 코드 테스트 기대한 대로 동작하는 코드를 작성하는 것은 어렵기에 단위 테스트를 작성하는 것이다. 동작하는 동시성 코드를 작성하는 것은 훨씬 더 어렵다. 동시성 처리가 필요한 애플리케이션 코드를 테스트하는 것은 기술적으로 단위테스트의 영역이 아닌 통합 테스트로 분류하는 것이 낫다. 스레드를 사용하느 코드에 대하 테스트는 느린 경향이 있다. 동시성 문제가 없다는 것을 보장하면서 실행 시간의 범위를 확장해야 하기 때문이다. 스레드에 관한 결함은 오랫동안 잠..

12장. 테스트 주도 개발. 작성하려는 코드가 있다면 항상 먼저 어떻게 그 코드를 테스트할지 고민해야 한다. 코드를 작성한 후에 어떻게 테스트할지 고민하기보다 작성할 코드를 묘사하는 테스트를 설계해야 한다. TDD에서 단위 테스트를 시스템의 모양을 잡고 통제하는 도구로 활용해야 한다. 단위 테스트는 소프트웨어를 어떻게 만들어야 할지에 관한 잘 훈련된 사이클의 핵심적인 부분이다. 따라서 TDD를 채택하면 소프트웨어 설계는 달라지고 아마도 더 좋아질 것이다. TDD의 주된 이익 단위 테스트를 사휘에 작성하여 얻을 수 있는 가장 명확한 이익은 코드가 예상한 대로 동작한다는 자신감인데 TDD에서도 동일하다. 또한 TDD를 잘 따른다면 구현하는 실질적인 모든 사례에 대해 단위 테스트를 작성하게 된다. 이런 단위 ..

11장. 테스트 리팩토링. 테스트 코드는 상당한 투자를 의미한다. 테스트는 결함을 최소화하고 리팩토링으로 프로덕션 시스템을 깔끔하게 유지시켜 주지만, 이것은 지속적인 비용을 의미하기도 한다. 이 장에서는 비용 증가로 이어지는 테스트 문제들을 해결할 것이다. 프로덕션 시스템을 리팩토링 하는 것처럼 테스트를 리팩토링하고 이해도를 최대화하며 유지 보수 비용을 최소화할 것이다. 불필요한 테스트 코드 테스트 코드가 예외를 기대하지 않는다면 단지 예외가 날아가게 두면 된다. 예외가 발생한 테스트는 오류로 표시되고 출력 창에 스택 트레이스가 보인다. 명시적인 try/catch 블록은 부가 가치가 업다. try/catch 블록을 제거하고 메서드의 원형을 IOException을 던지도록 변경하자. 추상화 누락 추상화로 ..

10장. 목 객체 사용. 이 장에서는 목 객체를 도입하여 고통을 주는 협력자에 대한 의존성을 끊는 방법과 항상 존재하는 장애물을 넘을 수 있게 도와주는 도구 활용법에 대해 알아본다. 목(mock)과 함께 단위테스트의 터널 끝에서 한 줄기의 빛을 볼 수 있을 것이라고 한다. 주소를 입력하는 대신 사용자는 지도에서 Profile 주소를 나타내는 지점을 선택할 수 있다. 애플리케이션은 선택된 지점은 위도와 경도 좌표를 AddressRetriever 클래스의 retrieve() 메서드로 넘긴다. 이 메서드는 좌표를 기반으로 생성된 Address 객체를 반환해야 한다. import java.io.*; import org.json.simple.*; import org.json.simple.parser.*; impo..