본문 바로가기

전체 글

토비의 스프링 - 2.6 2장 정리 2.6.1 정리 테스트는 자동화 및 빠른 실행을 해야함 main() 테스트 대신 JUnit 프레임워크를 이용한 테스트가 편리함 테스트 결과는 일관성 있어야 함. 환경이나 테스트 실행 순서에 따라 결과가 달라지면 안됨 테스트는 포괄적으로 작성해야 함. 충분한 검증이 이루어지지 않은 테스트는 없는것 보다 나쁨 코드 작성과 테스트 수행 간격이 짧을수록 효과적 테스트를 하기 쉬운 코드가 좋은 코드임 TDD 개발 방법은 매우 유용함 테스트 코드도 적절한 리팩토링 필요 @Before과 @After은 공통 중비 작업과 정리 작업을 처리할수 있음 스프링 테스트 컨텍스트 프레임워크를 이용하면 테스트 성능을 향상할 수 있음 동일 설정파일을 이용하면 하나의 애플리케이션 컨텍스트를 공유하도록 함 @Autowired를 사용하면.. 더보기
토비의 스프링 - 2.5 학습 테스트로 배우는 스프링 2.5.1 학습 테스트(Learning Test) 자신이 만들지 않은 프레임워크나 라이브러리 등의 테스트를 작성하는 것 자신이 사용할 API나 프레임워크의 기능을 테스트로 보면서 사용법을 익힘 프레임워크등 기능 검증 목적이 아님. 개발자의 이해도와 사용 방법을 검증하는 것임 학습 테스트를 통해 잘못된 지식이 바로잡기도 함 테스트 대상보다 테스트 코드 자체에 관심을 가져야 함 2.5.2 학습 테스트의 장점 다양한 조건에 따른 기능을 손쉽게 확인해 볼 수 있음 예제를 만들면서 학습을 하는것은 수동 테스트와 성격이 비슷함 반면에 학습 테스트는 자동화된 테스트 코드로 만들어지기 때문에 다양한 조건에 따라 기능이 어떻게 동작하는지 빠르게 확인 할 수 있음 학습 테스트 코드를 개발 중에 참고할 수 있음 수동 테스트.. 더보기
토비의 스프링 - 2.4 스프링 테스트 적용 2.4.1 기존 테스트의 문제점 @Test 애노테이션이 붙은 메소드를 테스트 할 때 마다 매번 새로운 오브젝트가 만들어지기 때문에, 매번 새로운 애플리케이션 컨텍스트가 생성됨 애플리케이션 컨텍스트에 있는 빈들이 초기화 시점에 많은 리소스를 할당하거나 스레드를 띄우는 경우가 발생해 테스트 안정성 및 속도가 떨어짐 빈은 싱글톤으로 만들어지기 때문에 상태를 가지지 않음(add(), get()을 한다고 해도 빈의 상태가 변경되지는 않음) 때문에 애플리케이션 컨텍스트를 매번 만들지 않고 공유를 해도 상관 없음 @BeforeClass 애노테이션은 테스트 클래스 전체에 딱 한번만 생성되는 스태틱 메소드를 만듦 스태틱으로 애플리케이션 컨텍스트를 저장해서 사용해도 되지만, 스프링이 직접 제공하는 애플리케이션 컨텍스트 테.. 더보기
토비의 스프링 - 2.3 개발자를 위한 테스팅 프레임워크 JUnit 2.3.1 JUnit 테스트 실행 방법 JUnitCore를 이용한 방법은 테스트의 수가 많아지면 관리하기 힘듦 IDE에서 지원하는 방식을 사용하면 편함 이클립스 IDE는 여러 정보를 보여줌 총 수행시간 실행한 테스트의 수 테스트 에러의 수 테스트 실패의 수 어떤 테스트 클래스를 실행했는지 @Test가 붙은 테스트 메소드의 이름 각 테스트 메소드와 메소드 수행 시간 빌드 툴에서 제공하는 JUnit 플러그인이나 태스트를 이용해 테스트 할 수 있음 테스트 결과를 HTML이나 텍스트 파일 형태로 추출 가능 2.3.2 deleteAll()의 getCount() 추가 현재 테스트는 수행되기 전에 수작업으로 DB의 데이터를 일일이 초기화 해야함 테스트가 외부 상태에 따라 결정되기도 함 add()의 데이터와 동일한 데.. 더보기
토비의 스프링 - 2.2 UserDaoTest 개선 2.2.1 테스트 검증의 자동화 add()와 get()을 통해 다시 DB에서 가져온 User 오브젝트의 정보가 정확히 일치하는가를 테스트 add()를 통한 등록 자체는 별다르게 검증할 것이 없음. add()이후 별다른 에러가 발생하지 않으면 성공으로 간주 add()를 통해 등록이 되지 않았다면, get()을 통해 가져오지 못할 것 이므로 get()을 통해 add()의 작업도 함께 확인 테스트 실패 종류 테스트 에러 테스트가 진행되는 동안에 에러가 발생해서 실패 테스트 실패 에러가 발생하진 않았지만, 결과가 기대한 것과 다르게 나오는 경우 main()은 제어권을 직접 가지므로, 프레임워크의 기본 동작원리인 IoC가 아니다. 따라서 프레임워크(스프링)에 main()을 사용하는 테스트는 적합하지 않음 Java.. 더보기
토비의 스프링 - 2.1 UserTest 다시 보기 2.1.1 테스트의 유용성 예상하고 의도했던 대로 코드가 정확히 수행되는지 검증 코드 수행 검증을 할 수 있는 테스트 코드 덕분에 코드 개선(리팩토링) 가능 기능을 추가할 때 유용하게 사용 가능하여 점진적 개발 가능 모든 기능을 구현하지 않아도 코드가 정상 동작하는지 확인 가능 💡 로그인 기능 웹사이트를 구현할 때 테스트가 없다면 파싱, DB 연결, SQL 실행 등 어디서 문제가 발생했는지 확인하기 어려움 2.1.2 작은 단위의 테스트 명확한 테스트 대상에만 집중해서 테스트하는 것이 바람직함 한번에 많은 테스트 대상을 테스트하면 어디서 오류가 발생하는지 찾기 어려움 테스트는 가능하면 작은 단위로 쪼개서 집중할 수 있어야 함 작은 단위의 코드에 대해 테스트 수행한 것을 단위 테스트(Unit Test)라 함.. 더보기
백준 - 11559 Puyo Puyo(Java) https://www.acmicpc.net/problem/11559 11559번: Puyo Puyo 총 12개의 줄에 필드의 정보가 주어지며, 각 줄에는 6개의 문자가 있다. 이때 .은 빈공간이고 .이 아닌것은 각각의 색깔의 뿌요를 나타낸다. R은 빨강, G는 초록, B는 파랑, P는 보라, Y는 노랑이다. www.acmicpc.net dfs 문제입니다. 가로12, 세로6 판에 빈 공간 또는 뿌요뿌요가 주어집니다. 한 위치에서 4방향으로 같은 모양의 뿌요뿌요가 있으면 해당 뿌요뿌요는 연쇄됩니다. 만일 연쇄가 될 수 있는 뿌요뿌요가 많아도 1연쇄로 칩니다. 뿌요뿌요가 연쇄가 되면 위에있던 뿌요들은 중력에 의해 아래로 내려옵니다. 이러한 규칙이 있을 때, 연쇄가 몇번 발생하는지 출력하면 되는 문제입니다. 자.. 더보기
토비의 스프링 - 1.9 1장 정리 1.9.1 정리 책임이 다른 코드를 분리(DB연결, DB실행)해서 두 개의 클래스로 만들었다.(관심사의 분리, 리팩토링) 바뀔 수 있는 쪽의 클래스는 인터페이스를 구현하게 하고, 다른 클래스에서 인터페이스를 통해 접근하도록 함. 정의하는 쪽의 구현 방법이 달라져 클래스가 변경되더라도, 그 기능을 사용하는 코드는 같이 수정할 필요가 없어짐(전략 패턴) 외부 오브젝트의 기능은 자유롭게 확장, 변경할 수 있도록 함(개방 폐쇄 원칙) 낮은 결합도와 높은 응집도 코드가 되어 코드가 깔끔해짐 제어권을 별도의 오브젝트 팩토리를 만들어 넘김.(제어의 역전/IoC) 전통적 싱글톤 패턴의 단점과 스프링의 싱글톤 레지스트리를 이용하여 싱글톤의 단점을 극볼할 수 있도록 함 설계 시점과 코드에는 클래스와 인터페이스 사이의 느슨.. 더보기

티스토리툴바