본문 바로가기

전체 글

토비의 스프링 - 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) 전통적 싱글톤 패턴의 단점과 스프링의 싱글톤 레지스트리를 이용하여 싱글톤의 단점을 극볼할 수 있도록 함 설계 시점과 코드에는 클래스와 인터페이스 사이의 느슨.. 더보기
토비의 스프링 - 1.8 XML을 이용한 설정 1.8.1 XML 사용 이유 오브젝트 사이의 의존정보를 일일이 자바 코드로 만들기 번거로움 자바코드는 틀에 박힌 구조 XML은 자바 코드와 달리 별도의 빌드 작업이 없고, 빠르게 변경사항 반영 가능 스키마나 DTD(Document Type Definition)을 사용해 정해진 포맷으로 작성 되었는지 확인 가능 1.8.2 XML 설정 DI 정보가 담긴 XML 파일은 를 루트 엘리먼트로 사용 태그로 빈 설정 XML 설정은 자바의 @Configraion, @Bean 설정과 동일 💡 @Configraion은 , @Bean은 과 같다고 생각하면 됨 @Bean 메소드를 통해서 얻을 수 있는 세 가지 정보 빈의 이름(id) @Bean 메소드 이름이 빈의 이름. 이 이름은 getBean() 에서 사용됨 빈의 클래스(c.. 더보기
토비의 스프링 - 1.7 의존관계 주입(DI) //의존관계 검색 public UserDao(){ DaoFactory daoFactory = new DaoFactory(); //daoFactory가 미리 정의한 이름 this.connectionMaker = daoFactory.connectionMaker(); } //의존관계 주입 public UserDao(ConnectionMaker connectionMaker){ this.connectionMaker = connectionMaker(); } 1.7.1 제어의 역전(IoC)과 의존관계 주입 IoC 단어는 스프링 서블릿 컨테이너처럼 서버에서 동작하는 서비스 컨테이너라는 뜻인지, 단순희 IoC 개념이 적용된 템플릿 메소드 패턴을 이용해 만들어진 프레임워크인지, IoC 특징을 지닌 기술인지 해석하기 애매함.. 더보기

티스토리툴바