중첩 클래스(nested class)독립적인 오브젝트로 만들어질 수 있는 스태틱 클래스(static class)자신이 정의된 클래스의 오브젝트 안에서만 만들어질 수 있는 내부 클래스(inner class) 내부 클래스는 다시 범위(scope)에 따라 세 가지로 구분된다.오브젝트 레벨에 정의되는 멤버 내부 클래스(member inner class)메소드 레벨에 정의되는 로컬 클래스(local class)이름을 갖지 않는 익명 내부 클래스(anonymous inner class) 로컬 클래스특정 메소드에서만 사용되는 것이라면 로컬 클래스로 만들 수 있다. 익명 내부 클래스클래스 선언과 오브젝트 생성이 결합된 형태로 만들어지며, 상속한 클래스나 구현할 인터페이스를 생성자 대신 사용해서 다음과 같은 형태로 만들..
템플릿 메소드 패턴변하지 않는 부분은 슈퍼클래스에 두고 변하는 부분은 추상 메소드로 정의하여 서브클래스에서 오버라이드하여 새롭게 정의해 쓰도록 하는 패턴기존의 상위 DAO 클래스에 불필요한 변화는 생기지 않도록 할 수 있으나 DAO 로직마다 상속을 통해 새로운 클래스를 만들어야 하기 때문에 제한이 많다. 또한 상위 클래스와 서브클래스들의 관계가 컴파일 시점에 이미 결정되므로 관계의 유연성이 떨어진다.전략 패턴은 개방 폐쇄 원칙(OCP)를 잘 지키는 구조이면서도 템플릿 메소드 패턴보다 유연하고 확장성이 뛰어나다. 오브젝트를 아예 둘로 분리하고 클래스 레벨에서는 인터페이스에만 의존하기 때문이다.
리소스 반환과 close()Connection과 PreparedStatement는 보통 제한된 수의 리소스(Connection, Statement)를 만들어 두고 필요할 때 이를 할당하고, 반환하면 다시 풀에 넣는 방식으로 운영된다. 이는 요청이 많은 서버환경에서 매번 새로운 리소스를 생성하지 않고 풀에 미리 만들어둔 리소스를 돌려가며 사용할 수 있다는 장점이 있다. 단, 사용한 리소스는 빠르게 반환해야 한다. 이때 close() 메소드가 사용한 리소스를 풀로 다시 돌려주는 역할을 한다.
버그 테스트 방법 2가지 1. 동등분할(equivalence partitioning)같은 결과를 내는 값의 범위를 구분해서 각 대표 값으로 테스트 하는 방법 각 결과를 내는 입력 값이나 상황의 조합을 만들어 모든 경우를 테스트 해보는 것이 좋음2. 경계값 분석(boundary value analysis)에러는 동등분할 범위의 경계에서 주로 많이 발생한다는 특징을 이용, 경계의 근처에 있는 값을 이용해 테스트하는 방법 ex) 숫자의 입력 값인 경우 0이나 그 주변 값 또는 정수의 최대값, 최소값 등으로 테스트
태스트 코드에 의한 DI테스트를 위한 별도의 DI 설정컨테이너 없는 DI 테스트DI를 테스트에 이용하는 세 가지 방법 중 어떤 것을 선택해야 할까?항상 스프링 컨테이너 없이 테스트할 수 있는 방법을 가장 우선적으로 고려하자. 이 방법이 테스트 수행 속도가 가장 빠르고 테스트 자체가 간결하다.여러 오브젝트와 복잡한 의존관계를 갖고 있는 오브젝트를 테스트해야 할 경우라면, DI 방식의 테스트를 이용하는 것이 편리하다.예외적인 의존관계를 강제로 구성해야 하는 경우, @DirtiesContext 애노테이션을 이용한 수동 DI를 활용하자.그냥 동등한 운영계 DB에 접근하면서도 운영계에 영향 없이 테스트 할 수 있는 방법은 없나?
JUnit 테스트 수행 방식테스트 클래스에서 @Test가 붙은 public이고 void형이며 파라미터가 없는 테스트 메소드를 모두 찾는다.테스트 클래스의 오브젝트를 하나 만든다.@Before가 붙은 메소드가 있으면 실행한다.@Test가 붙은 메소드를 하나 호출하고 테스트 결과를 저장해둔다.@After가 붙은 메소드가 있으면 실행한다.나머지 테스트 메소드에 대해 2~5번을 반복한다.모든 테스트의 결과를 종합해서 돌려준다.* 각 테스트 메소드를 실행할 때마다 테스트 클래스의 오브젝트를 새로 만든다.
테스트 주도 개발(TDD, Test Driven Development)만들고자 하는 기능의 내용을 담고 있으면서 만들어진 코드를 검증도 해줄 수 있도록 테스트 코드를 먼저 만들고, 테스트를 성공하게 해주는 코드를 작성하는 방식의 개발 방법이다.테스트를 코드보다 먼저 작성한다고 해서 테스트 우선 개발(Test First Development)이라고도 한다.TDD의 기본 원칙인 "실패한 테스트를 성공시키기 위한 목적이 아닌 코드는 만들지 않는다"를 따랐다면 모든 코드는 빠짐없이 테스트로 검증된 것이라고 볼 수 있다.개발을 하다보면 자연스럽게 머릿속으로 테스트하게 된다. 그러나 머릿속에서 진행되는 테스트는 제약이 심하고, 오류가 많고, 반복하기가 힘들다. 이를 실제 코드로 끄집어 놓으면 TDD가 된다.
- Total
- Today
- Yesterday