reflection API 를 이용하여 매개변수로 넘어온 클래스의 종류 및 메소드 목록을 출력하는 메소드를 작성하시오.

public void printClass(Object object) {
	System.out.println(object.class.getName());
	System.out.println(object.class.getMethods());
}

XML 파서인 SAX 와 DOM 파서의 특징 및 장단점을 서술하시오.

JMX 에 대하여 서술하시오.

• 모니터링 API
• Java Management Extensions 의 약자로 자바 기반의 모든 애플리케이션을 모니터링 하며 JDK 5.0 부터 지원

JMX는 4단계 레벨로 이루어진다

• instrumentation level
• agent level
• distributed servide level
• addtional management protocol APIs

JMX를 모니터링할 수 있는 도구를 3개 이상 나열하고 링크도 포함시키시오.

• MBeans
  • https://docs.oracle.com/javase/tutorial/jmx/mbeans/standard.html
• Visual VM
  • http://visualvm.java.net/
• 원격??
• manager
  • https://www.manageengine.com/products/applications_manager/jmx-monitoring.html
• jconsole
  • http://docs.oracle.com/javase/7/docs/technotes/guides/management/jconsole.html
  • http://egloos.zum.com/entireboy/v/3695194

Web access log 의 패턴을 확인해 보고, 각 패턴에 대하여 서술하시오.

https://httpd.apache.org/docs/2.4/logs.html 를 참고하면 자세히 나온다

예시

127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326

포맷

LogFormat "%h %l %u %t \"%r\" %>s %b" common
CustomLog logs/access_log common

• 127.0.0.1 (%h)
  • 서버에 요청을 한 클라이언트(원격 호스트)의 IP 주소
• -(%l)
  • 출력에서 “빼기기호”는 요청한 정보가 없음을 나타냄
• frank (%u)
  • 이는 HTTP 인증으로 알아낸 문서를 요청한 사용자의 userid
• [10/Oct/2000:13:55:36 -0700] (%t)
  • 서버가 요청처리를 마친 시간
• “GET /apache_pb.gif HTTP/1.0” ("%r")
  • 클라이언트의 요청줄
• 200 (%>s)
  • 이는 서버가 클라이언트에게 보내는 상태코드
• 2326 (%b)
  • 마지막 항목은 응답 헤더를 제외하고 클라이언트에게 보내는 내용의 크기를 나타냄

자바 GC 종류를 모두 나열 하시오.

GC - Garbage Collection 의 약자이다.

• 기본적으로 메모리할당
• 사용중인 메모리 인식
• 사용하지 않는 메모리 인식

역할을 담당한다.

GC의 종류는 크게 두가지 타입으로 나뉘며 마이너GC, 메이저GC라고한다

• 마이너GC = Young 영역에서 발생하는 GC
• 메이저GC = Old 영역이나 Perm 영역에서 발생하는 GC

GC 상황을 모니터링할 수 있는 도구를 3개 이상 나열하고, 링크도 포함시키시오.

• jstatd
  • 도구는 아닌가..? http://d2.naver.com/helloworld/6043
• VisualVM + Visual GC
  • http://visualvm.java.net/

• gca
• http://glezen.org/gca/

다음과 같이 resultCode, resultMessage, siteId JSON 스트링이 있고, 해당 JSON 스트링 값을 ConstraintData DTO 클래스의 프로퍼티에 bind 시키기 위해 다음과 같은 코드를 사용했다.

허나, 이와 같이 코드를 작성하게 된다면 다음과 같은 예외를 접하게 될 것이다.

이유는 JSON 스트링에는 resultCode, resultMessage name이 존재하지만 ConstraintData 클래스에는 해당 멤버 변수가 존재하지 않기 때문이다.

예외 내용을 살펴보면 "알려지지 않은 resultCode" 라고 표시된다.

전달해 주는 JSON 스트링 값을 모두 다 받아서 처리해야 한다는 규칙이 없다면 내가 필요한 값만 ConstraintData 클래스에 정의하여 바인드 시키면 될 것이다.

그러기 위해선 다음과 같이 두 가지 방법을 사용하면 된다. 

첫 번째는 ObjectMapper 클래스를 초기화 한 후 다음의 설정을 추가

두 번째는 ConstraintData 클래스에 다음의 annotation을 추가

출처 : 탁구치는 개발자 - http://lng1982.tistory.com/180   

spring-boot 관련글은 아래 url을 참고하세요
https://hyeonguj.github.io/2020/01/15/Spring-주기적으로-코드-실행하기-Schedule/

블로그 자료를 이전하고 있습니다.
https://hyeonguj.github.io/

자바 성능 모니터링 도구

• profiling
• APM
  • scouter (LG) : 제니퍼와 유사함 , 리얼타임
  • pinpointer (Naver) : 사후 분석

서버의 성능은 ? - TPS

서버의 성능을 늘리려면 ? -> 서버를 늘린다!  단, 병목을 잡아줘야함 병목현상 -> 주로 CPU에서 발생함.

잘 설계된 서비스라면 DB에서 부하가 일어남

BCI - Byte Code Instrument

함수 전/후에 원하는 코드를 삽입하여 실행 시킬 수 있다 앞뒤로 성능 측정하는 코드를 넣고, 상태를 확인하는 식으로 구현한다. 프로파일 같은 경우 JVM을 변경하여 사용하기도 한다.

로그 - log

로그파일 (log file)

피크때는 몇기가씩 쌓이기도함. 서비스에 따라서 10분단위 / 시간단위 / 날짜단위로 파일을 저장한다 로그가 쌓이면 -> 디스크 풀 -> 망함!! (터미널도 접속못함) 디스크를 수시로 확인해야 한다 -> du / df 명령어를 통해서 디스크를 확인 로그는 요청이 나갈때 찍힌다

메모리/cpu등 어떤 문제가 생긴다!! -> L4 끊고 로그를 확인해봐야됨. ( 요청이 나갈때 처리되기 때문 ) 도저히 못찾으면? -> 밤마다 껏다키는 스크립트라도??

성능측정 - (각종 지표)

일반적인 데이터는 평균이나 중간값이나 비슷함. WAS응답속도의 경우 중간값이 더 크다.

분산, 표준편차가 크다 -> 응답 속도가 들쭉날쭉하다 95th, 99th  -> 95%, 99%의 사용자는 어떤 성능을 보장한다는 의미로 사용함

Abstract ? Interfae?

Abstract (extends) 확장!

중간역할. 비슷한 코드가 여러번 나올때 그것을 모아서 구현해 놓고 사용

Interface (implements) 구현!

다중상속 불가능 함수를 반드시 구현해야한다. 내부를 모르더라도 그 기능을 하는 함수를 밖에서 사용 할 수 있게 . (User Interface처럼)

Static

static 으로 선언된 변수는 Class에 하나다, WAS에 올릴 경우 이 데이터는 계속 쌓이게 되고 메모리 릭의 원인이 된다 - 조심해서쓰자

static block - 값을 초기화 할때 ( Map 같이 초기화할때 new 하고나서 값넣기 등 더해야 하는 경우)

public class StaticImportSample
{
    static String rookie;
    static Map\\<String,String\\> map
    static {
        rookie = "test"
        map = new HashMap\\<String,String\\>();
        map.put("key", "value");
    }
}

Lambda

오라클 - **lambda Quick Start - **http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/Lambda-QuickStart/index.html#section1

 package java.awt.event;
 import java.util.EventListener;

 public interface ActionListener extends EventListener {
    public void actionPerformed(ActionEvent e){
        system.out.println(e.getSources());
    {
}

인터페이스안에 메소드가 하나밖에 없는경우! 이렇게 Lambda 쓸 수 있음.

ActionListioner listener2 = e-\\>  System.out.println(e.getSourcesI();

ActionListioner listener2 = e-\\> {
    //여러줄 가능
    System.out.println(e.getSourcesI());
};

Stream

public class Sample { public static void main(String[] argv) { List multiplesOf3 = new ArrayList<>(); for (long loop = 1; loop < 10; loop++) { multiplesOf3.add(loop); }

	multiplesOf3.stream()
	.filter(i-\> i%3==0 && i!=0)
	.forEach(System.out::println);		
} }

stream 으로 각종 다양한 일을 할 수 있다 .filter() .sort() .map() …

자세한건 여기,,,. http://www.oracle.com/technetwork/articles/java/ma14-java-se-8-streams-2177646.html

GC - garbage

http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/gc01/index.html

필요없는것은 지워줘야함.

과정

1. Marking
2. Normal Deletion 2a : Deletion with Compacting

Generation Garbage Collection Process

hotspot Heap Structure

1. 처음에는 무조건 Eden 으로감 2. Eden 꽉차면 - 필요없는거 지우고 servivor copy - 한쪽으로만 모음 3. Eden 꽉차면 -\> 옮기고\, servivor 은 count 가 1씩 증가됨 .. 6, 늙은 애들(count > threshold) Tenured로 이동한다

young 쪽이 빠름! old쪽이 느림! young 쪽에서 쓸모없는거 지우고, 오래 살아 남은건 오래 살아남을 가능성이 높으니 더 보관하다

OOP

• http://www.javatpoint.com/java-oops-concepts - name convention / constructor / static 등 객체지향에 관한 다양한 concepts를 알 수 있음

블로그 자료를 이전하고 있습니다. 많은방문 부탁드립니다 ( https://hyeonguj.github.io/ )

이 블로그의 자료는 이관된 페이지에서도 보실 수 있습니다.

https://hyeonguj.github.io/2017/01/23/Maven-Profile-를-통해-설정-관리하기/

property의 필요성

아주 작은 프로젝트, 절대로 변하지 않을 프로젝트라면 상관없다.

하지만 단순히 서비스를 어느서버에서 하느냐, 디비를 어느것을 이용하느냐, 인증을 어디것을 사용하느냐에 따라 코드를 바꿔야 한다.

이런 불상사..

자주 바뀌는 코드, 코드말고 다른 의존성에 의한 설정값 등의 셋팅이 코드에 있다면 어떤 일이 발생할까?

OAuth 인증 부분

다음은 payco, facebook 을 통한 Oauth 인증 설정 코드 중 일부이다

	private static final String FACEBOOK_LOGIN_PAGE_URL = "https://www.facebook.com";
	private static final String FACEBOOK_LOGIN_PAGE_PATH = "/v2.8/dialog/oauth";
	private static final String FACEBOOK_CLIENT_ID = "
	private static final String FACEBOOK_CLIENT_SECRET_KEY = 
	
	private static final String FACEBOOK_REDIRECT_URL = "http://dev-service.domain.com/facebookAccessToken.do";
//	private static final String FACEBOOK_REDIRECT_URL = "http://localhost:8080/letsparty/facebookAccessToken.do";
	private static final String FACEBOOK_REQUEST_SCOPE = 
	private static final String FACEBOOK_REQUEST_TOKEN_PAGE_URL = "https://graph.facebook.com";
	private static final String FACEBOOK_REQUEST_TOKEN_PAGE_PATH = "/v2.8/oauth/access_token";
	private static final String FACEBOOK_REQUEST_DATA_PAGE_URL = "https://graph.facebook.com";
	private static final String FACEBOOK_REQUEST_DATA_PAGE_PATH = "/me";
	private static final String FACEBOOK_REQUEST_DATA_FIELD = "id,name,email,picture";

	private static final String PAYCO_LOGIN_PAGE_URL =
	private static final String PAYCO_LOGIN_PAGE_PATH = 
	private static final String PAYCO_CLIENT_ID = 
	private static final String PAYCO_CLIENT_SECRET_KEY = "
	
	private static final String PAYCO_REDIRECT_URL 
	private static final String PAYCO_RESPONSE_TYPE =
	private static final String PAYCO_SERVICE_PROVIDER_CODE 
	private static final String PAYCO_USER_LOCALE = 
	private static final String PAYCO_REQUEST_TOKEN_PAGE_URL = ";
	private static final String PAYCO_REQUEST_TOKEN_PAGE_PATH =
	private static final String PAYCO_GRANT_TYPE = 
	private static final String PAYCO_REQUEST_DATA_PAGE_URL = 
	private static final String PAYCO_REQUEST_DATA_PAGE_PATH =
    //....

약 15개 정도 되는 정보들이 박혀있는것을 볼 수 있다.

특히

    private static final String FACEBOOK_REDIRECT_URL = "http://dev-service.domain.com/facebookAccessToken.do";
//  private static final String FACEBOOK_REDIRECT_URL = "http://localhost:8080/letsparty/facebookAccessToken.do";

를 보면 dev 서버에 올려서 테스트 하는 경우와 local 에서 테스트 할 경우에 redirect 주소를 다르게 넘겨주어야 하고, 빈번히 바뀌는 부분이기 때문에 주석처리를 해서 사용한것을 볼 수 있다.. 수작업…ㄱ-)

DB

데이터 베이스 부분도 마찬가지이다

    <bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
        <property name="driverClassName" value="com.mysql.jdbc.Driver"/>
        <property name="url" value="jdbc:mysql:ServerAddress:13306/letsparty?characterEncoding=utf8"/>
        <property name="username" value="id"/>
        <property name="password" value="pass"/>
    </bean>    

driverClassName은 그렇다 쳐도, url의 경우는 local,dev,real,test 와같은 상황에 따라 바뀐다. 따라서 상황에 따라 수동으로 입력 하는것은 매우 번거러운 일이다.

Profile

우리TF는 local,dev,real 상황에 따라 바뀌는 설정들을 미리 정해놓고, 컴파일 타임에 선택하려 한다. 후보는

• maven profile
• spring profile

Spring

spring profile의 특징은 런타임에 profile을 바인딩하여 설정 할 수 있는 것이다.

@Configuration
public class AppConfig {

	@Profile("dev")
	@Bean
	public CacheManager cacheManager() {	//...	}

	@Profile("live")
	@Bean
	public EhCacheManagerFactoryBean ehCacheCacheManager(){  	//...	}

	@Profile("testdb")
	@Bean
	public DataSource dataSource() {	//...	}
}

@Profile 을 통해 적용되는 코드를 나누고,

web.xml에서 다음과 같은 설정을 통해 profile을 설정한다.

<context-param>
    <param-name>spring.profiles.active</param-name>
    <param-value>live</param-value>
</context-param>

<context-param>
    <param-name>spring.profiles.active</param-name>
    <param-value>dev, testdb</param-value>
</context-param>

Maven

maven 을 통한 profile 관리는 compile 시점에 mvn -P[profileName] clean package 명령어를 통해 어떤 자원을 사용할지 결정한다.

1. profile 설정파일들이 들어갈 폴더구조를 만든다. 

2. profile에 해당하는 resource 폴더구조를 적어준다

pom.xml

<project>

	<profiles>
		<profile>
			<id>local</id>
			<activation>
				<activeByDefault>true</activeByDefault>
			</activation>
			<properties>
				<environment>local</environment>
			</properties>
		</profile>
		<profile>
			<id>real</id>
			<properties>
				<environment>real</environment>
			</properties>
		</profile>	        
		<profile>
			<id>dev</id>
			<properties>
				<environment>dev</environment>
			</properties>
		</profile>
	</profiles>
    
    <build>
		<resources>
			<resource>
				<directory>src/main/resources/${environment}</directory>
			</resource>
		</resources> 
	</build>

</project>

사용

1. property로 뺄 부분을 별도의 파일로 만든다
2. 그리고 위 사항을 .java 나 .xml 에서 사용한다.

• 변수에서 사용

clientId = ....
clientSecret = ....
paycoHost = ....
authURI = ....
accessURI = ....
profileHost = ...
profileURI = ....
redirectURI = ....

@Value("#{payco['paycoHost']}")
String PAYCO_LOGIN_PAGE_URL;	

@Value("#{payco['clientId']}")	
String PAYCO_CLIENT_ID;

• xml 에서 사용

mysql.properties

jdbc.driver = com.mysql.jdbc.Driver		
jdbc.url = jdbc:mysql://localhost:3306/guestbook		
jdbc.username = root		
jdbc.password = gusrn 

<bean
    class= "org.springframework.beans.factory.config.PropertyPlaceholderConfigurer" >
    <property name= "locations">
    <value>classpath:/mysql.properties</value >
    </property>
</bean>

<bean id="dataSource"
    class= "org.springframework.jdbc.datasource.SimpleDriverDataSource" >
    <property name= "driverClass" value="${jdbc.driverClass}" />
    <property name= "url" value ="${jdbc.url}" />
    <property name= "username" value="${jdbc.username}" />
    <property name= "password" value="${jdbc.password}" />
</bean>

진행상황

OAuth 인증, Database, Object Storage 등 외부 의존도가 잇거나, 용도에 따라 달라지는 환경을 분리하는 작업을 진행중이다

• [v] OAuth 인증
• [v] Database
• [v] Object Storage

블로그 자료를 이전하고 있습니다. 많은방문 부탁드립니다 ( https://hyeonguj.github.io/ )

이 블로그의 자료는 이관된 페이지에서도 보실 수 있습니다.

https://hyeonguj.github.io/2019/01/31/spring-unit-test/

Unit test 구현

[Spring MVC 구조에서 역할에 따른 Unit test]

‘lets party’ 라는 주제로 기술개발교육 프로잭트를 진행중이다. 이때 Spring MVC 로 개발을 하였고 이에 따른 테스트도 과제로 주어졌다.

‘lets party’는 크게 3개의 레이어로 구성되어 있다.

• Controller :
  1. 처리해야 할 데이터를 브라우저에게 받는다.
  2. 담당할 service를 선택하여 호출한다
  3. 처리한 데이터를 다음 페이지에서 볼 수 있게 셋팅한다.
  4. 이동할 페이지를 리턴한다
• Service :
  1. 데이터를 받아 비지니스 로직을 처리한다.
  2. DB의 활용이 필요한 경우 해당 처리를 하는 DAO를 호출한다
• DAO
  1. db를 활용할 데이터를 받는다
  2. 역할을 하는 mapper를 호출하여 처리하게 한다.

이와 같이 역할이 다르다 보니 테스트 하는 방법도 달라진다. 기본원칙은 ‘분리’ 서로가 서로에게 의존하지 않아서, 다른 객체와는 상관 없이 항상 같은 결과가 나오야 한다. (하면서 배웠지만, 적용이 안된 부분도 많다..)

각각의 테스트 방법이 조금씩 다르지만 기본적으로 하는일은 똑같다. 목적 : input에 대한 output이 잘 나오는지 확인하기! 과정 : 입력값 가정하기 -> 호출하기 -> 검증하기 (호출검증 및 output 검증)

Controller

Controller의 테스트는 크게 2가지를 테스트 하였다

1. 브라우저에서 “/pageName.do”를 호출 했을때 해당 controller를 호출하는지, 그리고 2xx, 3xx와같은 결과를 받는지

mockMvc.perform(get("/partyDetail.do")
				.param("partyId","1")
				.session(httpSession)
				).andExpect(status().isOk());

위 코드는 “/partyDetail.do” 를 브라우저에서 호출했을때, 해당 controller가 잘 호출 되는지를 확인 한 것이다. get방식으로 전달된 데이터는 param() 으로 받을 수 있고, HttpSession은 .session으로 받는다.

1. Controller에서 재대로 된 Service를 호출 하는지

다른 함수가 잘 호출 되었는지는 Mockito의 verify를 활용하여 검사 할 수 있다.

verify(partyService).selectParty(1);

위 함수는 partyService.selectParty() 함수가 1이라는 인자값을 통해 호출되었는지 확인하는 함수이다.

그 외에도 다양한 방법으로 함수호출을 test 할 수 있다.

verify(partyService, times(3)).selectParty(1);

times(3) 을 통해 3번 호출 되었는지 검사한다.

verify(partyService, times(3)).selectParty(anyInt());

anyInt()를 통해서는 ‘1’이라는 인자 외에 int형으로 된 값으로 호출되었는지 테스트 할 수 있다.

Controller 는 Unit Test 가 아닌 통합 테스트로 진행 했습니다.

유닛테스트로 구현 할 경우, 인터페이스의 구현체를 생성자를 통해 생성한 후 호출하여 테스트합니다.

이렇게 할 경우 Spring 에 대한 의존성을 모두 삭제합니다.

Service

service는 비지니스 로직을 처리하는 부분으로 test도 상대적으로 좀 복잡하다. 일반적으로 과정은 다음과 같다

@Test
public void joinPartyFirstJoinTest() {
	when(partyDAO.getNumOfUserParty(Mockito.any(UserPartyVO.class))).thenReturn(0);	
	when(partyDAO.checkJoin(Mockito.any(UserPartyVO.class))).thenReturn(0);

	partyService.joinParty(userPartyVO);

	verify(partyDAO).getNumOfUserParty(Mockito.any(UserPartyVO.class));
	verify(partyDAO).insertUserParty(Mockito.any(UserPartyVO.class));
	verify(partyDAO).increasePublicParticipantsCount(anyInt());
}

when().thenReturn() 을 통해 비지니스 로직에서 쓰이는 의존성 있는 함수들의 값들을 미리 세팅한다. 이후 함수를 호출하고 (partyService.joinParty(userPartyVO)) 다른 함수들을 잘 호출 했는지, 기능을 잘수행했는지 검증한다.

DAO

DAO는 데이터를 가지고 오는것을 목표로 하고있다. 이후 교육과정에서 Unit test라기보다는 integration test라고 부르는것을 들었다. DB에 의존성이 있고, 이를 잘 수행하여 반영이 되는지를 테스트 하기 때문이다.

letsparty에서는 DAO는 한번에 하나의 쿼리만 처리하게 되어 있기 때문에 간단하게 테스트 한다.

단, test 전 후에 DB의 상태가 같아야 하기 때문에 rollback 이 필요한데, Spring 에서 제공하는 rollback은 mybatis와 함깨 사용 할 수 없다. (따라서 수동으로…)

@Test
public void insertPartyTest() throws Exception {
	int sizeOfBeforeInsert = partyDAO.selectAll().size();

	partyDAO.insert(partyVO);
	int insertedPId = partyVO.getPartyId();		
	int sizeOfAfterInsert =  partyDAO.selectAll().size();

	assertEquals("insertTest - inserted party id  : "+insertedPId , sizeOfBeforeInsert+1, sizeOfAfterInsert);

	//clean database
	partyDAO.deletPartyeById(insertedPId);
}

insert를 하는 DAO를 테스트하는 코드이다. partyDAO.selectAll(), partyDAO.deletPartyeById() 도 함깨 사용하는데, partyDAO.selectAll() 를 사용하여 insert 전 후에 크기를 비교하여 1개가 잘 들어갔는지 확인한다. 이후 partyDAO.deletPartyeById()를 통해 rollback 한다.

이 함수들도 모두 test를 해야한다. selectAll()함수가 잘 동작하지 않는다면 insert는 재대로 test된것이 아니기 때문이다. 함깨 테스트를 해도 되는것인지, 그래도 각각을 분리해서 테스트를 해야하는것인지는 잘 모르겠다.

DAO 는 Unit Test 가 아닌 통합 테스트로 진행 했습니다.

DAO특성상 DB와 함깨 연동 하는것을 테스트 하였습니다.

느낀점

test코드를 작성하다보니 기존 코드의 단점이나 수정해야할 부분도 함깨 보이기 시작했다. test작성만 하는것이 아니라 리팩토링까지 함깨 하다보니 시간이 꽤 걸렸다

목표로한 coverage가 올라가는것을 보니 기분이 좋았다.

토비의 스프링 요약 3장 - 템플릿 (1)

• 개방 폐쇠의 원칙 OCP : 확장에는 열려있고, 변경에는 닫혀있다.
• 템플릿
  • 변경이 거의 일어나지 않으며,
  • 일정 패턴으로 유지되는 특성을 가진 부분 -> 자유롭게 변형되는 성질을 가진 부분으로 부터 독립

[ 3.1 다시 보는 초난감 DAO ]

예외처리 기능을 갖춘 DAO

• jdbc에서 예외가 발생하면 잡아줘야됨 : 리소스반환 필수!
• try-catch를 이용해 예외처리.-finally 를 통해 리소스반환을 한다.

[ 3.2 변하는 것과 변하지 않는 것 ]

JDBC try/catch/finally 를 그냥 사용할 경우 문제점

• 중첩구조로 되어있어 매우 답답함
• 중복된 코드
• 실수 가능성

템플릿 메소드를 활용한 분리

• 변하지 않는 부분은 남겨두고, 변하는 부분을 따로 빼서 Abstract method로 만듬.
• 이 클래스를 상속받아 자식에서 Abstract method를 구현함.
• 바뀌는 부분만 자식에서 갈아끼워가며 원하는 형태로 구현가능!
• 단, 상속을 통해서만 가능하다는점..-> 다양한 제약사항

전략 패턴

• 순서
  • 변하지 않는 맥락 context
  • preparedStatement를 만들어 줄 외부 기능 호출
  • 받아서 실행
  • 예외는 밖으로던지고,
  • 끝나면 적절히 닫아줌.
• preparedStatement가 고정되어 있으면 OCP라고 할 수 없음

DI적용을 위한 클라이언트/컨텍스트 분리

• 클라이언트가 전략을 정하고,
• context에서는 그 전략을 받아서 실행만!

public void deleteAll() thorws SQLException{
	StatementStrategy st - new DeleteAllStatement(); //전략 설정
    jdbcContextWithStatementtStrategy(st);			// context에 DI넣어서 실행
}

[ 3.3 JDBC 전략 패턴의 최적화 ]

추가정보

• delete와 달리 add 같은거는 어떤걸 추가할지에 대한 추가정보가 더필요함.
• 그럴때는 입력 받아서 field로 만들어주면됨

public class AddStatement implements StatementStrategy{
	User user;
    
    public AddStatement(User user){
    	this,user = user;
    }
}
//....

로컬 클래스

• 위와같이 작성하면 delete, add와 같이 DAO접근하는 전략하나마다 class가 생기게 된다

• 어차피 UserDAO 밖에 사용하지 않으니 내부 클래스로 만들어준다

• 자바에서 로컬 변수처럼 클래스를 선언 하는 방법임
• 외부 파라메터는 final로 선언하는것이 좋음 : 외부변수를 받아 그대로사용, 변조 안함.

public void add(final User user) thorws SQLException{
	public class AddStatement implements StatementStrategy{
	//User user;
    /*
   		public AddStatement(User user){
    		this.user = user;
    	}
    */  
        public PreparedStatement makePreparedStatement(Connection c) {
        	//...
        	return ps;
        }
    }
    
    StatementStrategy st = new AddStatement(user);
    jdbcContextWithStatementStrategy(st);       
}

익명 내부 클래스

• AddStatement()의 경우 add()를 위해 생성된 클래스로 이미 사용처가 정해짐 -> 이름 필요 없음.
• delete도 마찬가지..

pulbic void deleteAll() throws SQLException{
	jdbcContextWithStatementStrategy(
    	new StatementStarategy(){
        	public PreparedStatement makePreparedStatement(Connection c) throws SQLException{
            	return c.prepareStatement("delete from users");
            }
        }    	
    )
}

[ 3.4 컨텍스트와 DI ]

...

토비의 스프링 요약 (ch2 -테스트)(2)

Autowired : xml에 등록한 Bean과 같은 타입을 찾아서 DI해준다.

절대바뀌지 않는 상황에도 인터페이스를 활용한 DI를 적용해야할까?

• YES!!
  • 절대로 바뀌지 않는것은 없다
  • 다른 차원의 서비스를 도입 할 수 있다 - (예: 부가기능으로 count를 한다던지..)
  • 효율적인 테스트를 위해서

테스트 코드에 의한 DI

• 테스트에서, 실제로 사용하는 DB를 사용? -> 위험
• 테스트 코드 내에서 직접 DI하기 \
• @DritiesContext : 해당 테스트에서 에플리케이션 컨텍스트 상태를 변경하겠다 (예 : db변경)

테스트를 위한 별도 DI설정

• 수동으로하면 번거롭다
• test-applicationContext.xml 생성!

<!-- url 부분에 test시에 사용할 DB로 바꿈! -->
<bean id="dataSoource" class="org.springframework.jdbc.datasource.SimpleDriverDataSource">
	<property name="driverClass" value="com.mysql.jdbc.Driver" />
    <property name="url" value="jdbc:mysql://localhost/testdb" />
    <property name="username" value="user" />
    <property name="password" value="pass" />
</bean>

• test시에 @ContextConfiguration에 있는 lotation 을 test용으로바꿈,

컨테이너 없이 DI테스트

• 목적이 분명하다면 해당 Object를 직접 생성하여 만든다
• API에 의존하지 않고 관심에만 집중하여 깔끔하게 만든다.
• API에 종속되지 않고 비 침투적 기술로, 스프링에 의존하지않고도 DI가능

어떤것이 좋은가??

• 일단 컨테이너 없이 테스트 하는것을고려
• 복잡하다면 Spring 설정을 사용
• 영향을 주지 않게 하려면 테스트 설정을 따로 만든다.

학습테스트 - learning test

• 다른사람이 만든 코드와 기능에 대한테스트
• 프레임워크나 라이브러리에 대해서도 테스트

학습 테스트의 장점

• 해당 코드의 기능을 다양한조건을 활용해서 쉽게 확인할 수 있음
• 테스트 코드를 참고하여 개발에 활용 할 수 있음.
• 업데이트할때 호환성 검증
• 테스트 코드 작성 훈련
• 새로운 기술을 배울대 즐거워짐…??? (오래 기억에 남는다)

버그테스트

• 요류를 알려줄 수 있는 테스트
• 버그를 알았을 경우, 그 버그로 인해 실패할만한 케이스를 만들고 성공하도록 코드수정
• 장점
  • 테스트의 완성도가 높아짐
  • 버그의 내용을 명확하게 분석 할 수 있다.
  • 기술적인 문제를 해결하는데 도움이 됨.

정리

• 테스트는 자동화, 빠르게실행가능해야함 -> JUnit사용
• 일관성 보장, 순서에따라 달라지며안됨
• 테스트하기 좋은코드가 좋은코드
• 테스트를 먼저 만들고 이를 성공으로바꿔가는 TDD방법
• @Before, @After와같은 작업으로 공통코드를 줄일 수 있음
• 스프링 테스트 컨텍스트 프레임워크를 사용하여 성능 향상 가능
• @Autowired를 사용하여 오브젝트에 DI 할 수 있음
• 오류에 대비해 버그테스트를 만들어 놓으면 좋음
• 기술의 사용방법을 익히고 이해를 돕기위해 학습 테스트를 작성하자.