반응형

테스트 케이스를 작성을 할때 내가 어렵게 생각했던것은 2가지 이다.

1. Mock 으로 테스트케이스를 작성할 것인가? 아니면 실제 데이터를 가지고 작성할 것인다.

2. 테스트용 DB를 따로 둬야 할까?

이 2가지가 항상 풀리지 않는 난제 같았다. 그런데 갑자기 뭔가 기준을 정해서 하면 되지 않을까 라는 생각이 들었다. 어떻게 보면 당연한 이야기 이긴 하지만. 테스트케이스를 작성하려는 클래스들의 역할에 생각해 보고 그에 맞는 테스트 케이스를 작성하면 되는 것이다. 

Spring Boot 프로젝트를 보면 테스트케이스를 작성하는 클래스들로 다음과 같은 것들을 꼽을 수 있다.

1. Repository
2. Service
3. Controller
4. RestApiController

그럼 우선 이번 글에서는 Repository 에 대해서만 살펴보려고 한다. Repository 는 실제로 DB 와 연결되어서 CRUD를 할 수 있는 클래스이다. Repository 클래스에 정의되어 있는 메소드를 통해서 내가 원하는 데이터를 가져올 수 있는지, 아니면 수정이 되는지 여부를 확인 하는 테스트를 작성하면 된다. 그리고 이부분은 결국 DB의 데이터가 필요하다.  Mock 으로 하기에는 실제 데이터를 가져오는지 여부가 의심(?) 스럽기 때문이다. 

@DataJpaTest
@RunWith(SpringRunner.class)
public class UserRepositoryTest {

    @Autowired
    private UserRepository userRepository;

    private Users users;
    @Before
    public void setup(){
        users = Users.builder()
                .email("test@test.com")
                .name("test")
                .status(UserStatus.APPLIED)
                .build();

        userRepository.save(users);
    }

    @Test
    public void getUsers(){
        List<Users> all = userRepository.findAll();
        Assert.assertNotNull(all);
        Assert.assertEquals(1, all.size());
    }

    @Test
    public void getUsersById(){
        Optional<Users> byId = userRepository.findById("test@test.com");
        Assert.assertNotNull(byId);
        Assert.assertEquals("test", byId.get().getName());
    }
}

@DataJpaTest 를 사용하면 테스트케이스 실행시에 MemoryDB 를 사용해서 실행을 한다.  테스트케이스를 실행해 보면 다음과 같은 로그를 볼 수 있다. 

Hibernate: drop table if exists users CASCADE 
Hibernate: create table users (email varchar(100) not null, name varchar(100) not null, user_status integer not null, primary key (email))
2021-02-17 10:56:06.114  INFO 2856 --- [    Test worker] o.h.e.t.j.p.i.JtaPlatformInitiator       : HHH000490: Using JtaPlatform implementation: [org.hibernate.engine.transaction.jta.platform.internal.NoJtaPlatform]
2021-02-17 10:56:06.120  INFO 2856 --- [    Test worker] j.LocalContainerEntityManagerFactoryBean : Initialized JPA EntityManagerFactory for persistence unit 'default'
2021-02-17 10:56:06.224  INFO 2856 --- [    Test worker] c.p.common.user.web.UserRepositoryTest   : Started UserRepositoryTest in 2.808 seconds (JVM running for 3.635)
2021-02-17 10:56:06.293  INFO 2856 --- [    Test worker] o.s.t.c.transaction.TransactionContext   : Began transaction (1) for test context [DefaultTestContext@588bc70b testClass = UserRepositoryTest, testInstance = com.polpid.common.user.web.UserRepositoryTest@4f8e0671, testMethod = getUsers@UserRepositoryTest, testException = [null], mergedContextConfiguration = [MergedContextConfiguration@34cf76 testClass = UserRepositoryTest, locations = '{}', classes = '{class com.polpid.common.user.SpringCommonUserApplication}', contextInitializerClasses = '[]', activeProfiles = '{}', propertySourceLocations = '{}', propertySourceProperties = '{org.springframework.boot.test.autoconfigure.orm.jpa.DataJpaTestContextBootstrapper=true}', contextCustomizers = set[org.springframework.boot.test.autoconfigure.OverrideAutoConfigurationContextCustomizerFactory$DisableAutoConfigurationContextCustomizer@127dfcc0, org.springframework.boot.test.autoconfigure.filter.TypeExcludeFiltersContextCustomizer@351584c0, org.springframework.boot.test.autoconfigure.properties.PropertyMappingContextCustomizer@d5d4db2d, org.springframework.boot.test.autoconfigure.web.servlet.WebDriverContextCustomizerFactory$Customizer@5948c9fa, [ImportsContextCustomizer@efe207e key = [org.springframework.boot.autoconfigure.cache.CacheAutoConfiguration, org.springframework.boot.autoconfigure.data.jpa.JpaRepositoriesAutoConfiguration, org.springframework.boot.autoconfigure.flyway.FlywayAutoConfiguration, org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration, org.springframework.boot.autoconfigure.jdbc.DataSourceTransactionManagerAutoConfiguration, org.springframework.boot.autoconfigure.jdbc.JdbcTemplateAutoConfiguration, org.springframework.boot.autoconfigure.liquibase.LiquibaseAutoConfiguration, org.springframework.boot.autoconfigure.orm.jpa.HibernateJpaAutoConfiguration, org.springframework.boot.autoconfigure.transaction.TransactionAutoConfiguration, org.springframework.boot.test.autoconfigure.jdbc.TestDatabaseAutoConfiguration, org.springframework.boot.test.autoconfigure.orm.jpa.TestEntityManagerAutoConfiguration]], org.springframework.boot.test.context.filter.ExcludeFilterContextCustomizer@61218ded, org.springframework.boot.test.json.DuplicateJsonObjectContextCustomizerFactory$DuplicateJsonObjectContextCustomizer@e767673, org.springframework.boot.test.mock.mockito.MockitoContextCustomizer@0, org.springframework.boot.test.context.SpringBootTestArgs@1], contextLoader = 'org.springframework.boot.test.context.SpringBootContextLoader', parent = [null]], attributes = map[[empty]]]; transaction manager [org.springframework.orm.jpa.JpaTransactionManager@4bc55dd0]; rollback [true]
Hibernate: select users0_.email as email1_0_0_, users0_.name as name2_0_0_, users0_.user_status as user_sta3_0_0_ from users users0_ where users0_.email=?
Hibernate: insert into users (name, user_status, email) values (?, ?, ?)
Hibernate: select users0_.email as email1_0_, users0_.name as name2_0_, users0_.user_status as user_sta3_0_ from users users0_
2021-02-17 10:56:06.747  INFO 2856 --- [    Test worker] o.s.t.c.transaction.TransactionContext   : Rolled back transaction for test: [DefaultTestContext@588bc70b testClass = UserRepositoryTest, testInstance = com.polpid.common.user.web.UserRepositoryTest@4f8e0671, testMethod = getUsers@UserRepositoryTest, testException = [null], mergedContextConfiguration = [MergedContextConfiguration@34cf76 testClass = UserRepositoryTest, locations = '{}', classes = '{class com.polpid.common.user.SpringCommonUserApplication}', contextInitializerClasses = '[]', activeProfiles = '{}', propertySourceLocations = '{}', propertySourceProperties = '{org.springframework.boot.test.autoconfigure.orm.jpa.DataJpaTestContextBootstrapper=true}', contextCustomizers = set[org.springframework.boot.test.autoconfigure.OverrideAutoConfigurationContextCustomizerFactory$DisableAutoConfigurationContextCustomizer@127dfcc0, org.springframework.boot.test.autoconfigure.filter.TypeExcludeFiltersContextCustomizer@351584c0, org.springframework.boot.test.autoconfigure.properties.PropertyMappingContextCustomizer@d5d4db2d, org.springframework.boot.test.autoconfigure.web.servlet.WebDriverContextCustomizerFactory$Customizer@5948c9fa, [ImportsContextCustomizer@efe207e key = [org.springframework.boot.autoconfigure.cache.CacheAutoConfiguration, org.springframework.boot.autoconfigure.data.jpa.JpaRepositoriesAutoConfiguration, org.springframework.boot.autoconfigure.flyway.FlywayAutoConfiguration, org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration, org.springframework.boot.autoconfigure.jdbc.DataSourceTransactionManagerAutoConfiguration, org.springframework.boot.autoconfigure.jdbc.JdbcTemplateAutoConfiguration, org.springframework.boot.autoconfigure.liquibase.LiquibaseAutoConfiguration, org.springframework.boot.autoconfigure.orm.jpa.HibernateJpaAutoConfiguration, org.springframework.boot.autoconfigure.transaction.TransactionAutoConfiguration, org.springframework.boot.test.autoconfigure.jdbc.TestDatabaseAutoConfiguration, org.springframework.boot.test.autoconfigure.orm.jpa.TestEntityManagerAutoConfiguration]], org.springframework.boot.test.context.filter.ExcludeFilterContextCustomizer@61218ded, org.springframework.boot.test.json.DuplicateJsonObjectContextCustomizerFactory$DuplicateJsonObjectContextCustomizer@e767673, org.springframework.boot.test.mock.mockito.MockitoContextCustomizer@0, org.springframework.boot.test.context.SpringBootTestArgs@1], contextLoader = 'org.springframework.boot.test.context.SpringBootContextLoader', parent = [null]], attributes = map[[empty]]]
2021-02-17 10:56:06.755  INFO 2856 --- [extShutdownHook] j.LocalContainerEntityManagerFactoryBean : Closing JPA EntityManagerFactory for persistence unit 'default'
2021-02-17 10:56:06.755  INFO 2856 --- [extShutdownHook] .SchemaDropperImpl$DelayedDropActionImpl : HHH000477: Starting delayed evictData of schema as part of SessionFactory shut-down'
Hibernate: drop table if exists users CASCADE

 

테이블을 생성하고 Before 에 정의 되어있는 데로 데이터를 insert 한후 테스트 가 종료되면 테이블을 Drop 한다. 이정도면 Repository에 정의 되어있는 메소드가 내가 생각한대로 동작을 하는지 검증하는데는 크게 문제가 없다. 실제 DB에서 가져오도록 설정도 가능하지만 내 기준에서 테스트는 실제 DB와는 분리 되어야 한다고 생각을 하기 때문에 메모리 DB가 적합한것 같다.

한가지 주의할 점은 도메인을 정의할때 필드를 DB의 예약어와 동일하게 작성을 하면 에러가 날 수 있다. 예를 들어 order 라는 필드가 있으면 테이블이 생성될때 에러가 난다. 

org.hibernate.tool.schema.spi.CommandAcceptanceException: Error executing DDL "create table users (email varchar(100) not null, name varchar(100) not null, order integer, user_status integer not null, primary key (email))" via JDBC Statement
	at org.hibernate.tool.schema.internal.exec.GenerationTargetToDatabase.accept(GenerationTargetToDatabase.java:67) ~[hibernate-core-5.4.18.Final.jar:5.4.18.Final]
	at org.hibernate.tool.schema.internal.SchemaCreatorImpl.applySqlString(SchemaCreatorImpl.java:439) [hibernate-core-5.4.18.Final.jar:5.4.18.Final]
	at org.hibernate.tool.schema.internal.SchemaCreatorImpl.applySqlStrings(SchemaCreatorImpl.java:423) [hibernate-core-5.4.18.Final.jar:5.4.18.Final]
	at org.hibernate.tool.schema.internal.SchemaCreatorImpl.createFromMetadata(SchemaCreatorImpl.java:314) [hibernate-core-5.4.18.Final.jar:5.4.18.Final]
	at org.hibernate.tool.schema.internal.SchemaCreatorImpl.performCreation(SchemaCreatorImpl.java:166) [hibernate-core-5.4.18.Final.jar:5.4.18.Final]
	at org.hibernate.tool.schema.internal.SchemaCreatorImpl.doCreation(SchemaCreatorImpl.java:135) [hibernate-core-5.4.18.Final.jar:5.4.18.Final]
	at org.hibernate.tool.schema.internal.SchemaCreatorImpl.doCreation(SchemaCreatorImpl.java:121) [hibernate-core-5.4.18.Final.jar:5.4.18.Final]
	at org.hibernate.tool.schema.spi.SchemaManagementToolCoordinator.performDatabaseAction(SchemaManagementToolCoordinator.java:156) [hibernate-core-5.4.18.Final.jar:5.4.18.Final]
	at org.hibernate.tool.schema.spi.SchemaManagementToolCoordinator.process(SchemaManagementToolCoordinator.java:73) [hibernate-core-5.4.18.Final.jar:5.4.18.Final]
	at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:316) [hibernate-core-5.4.18.Final.jar:5.4.18.Final]
	at org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:469) [hibernate-core-5.4.18.Final.jar:5.4.18.Final]
	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:1259) [hibernate-core-5.4.18.Final.jar:5.4.18.Final]
	at org.springframework.orm.jpa.vendor.SpringHibernateJpaPersistenceProvider.createContainerEntityManagerFactory(SpringHibernateJpaPersistenceProvider.java:58) [spring-orm-5.2.8.RELEASE.jar:5.2.8.RELEASE]
	at org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:365) [spring-orm-5.2.8.RELEASE.jar:5.2.8.RELEASE]
	at org

그렇기 때문에 이런 부분들을 조심하면 된다.

Repository 테스트에 대한 결론은 메모리 DB를 사용해서 실제 CRUD 를 테스트 해보면 된다.

이제 다음 글에서는 Service 테스트에 대해서 살펴볼 예정이다.

주의사항) 제 생각을 기준으로 작성하고 만든 소스코드이고 의견이기 때문에 틀린 부분이 있을수 있습니다.

 

728x90
반응형
저작자표시 비영리 변경금지

'Development > Java' 카테고리의 다른 글

Spring Boot Test Case 작성에 대한 생각 - Controller Test  (0) 2021.02.18
Spring Boot Test Case 작성에 대한 생각 - Service Test  (0) 2021.02.17
Spring Boot Data Jpa 를 사용한 Paging.  (0) 2019.11.11
[SpringBoot] @RequestBody 에 들어가는 Object 는 No-Argument Constructor 가 존재해야 한다.  (0) 2019.10.21
[Spring Boot] There is no PasswordEncoder mapped for the id "null"  (0) 2019.09.09
반응형

테스트 케이스를 작성하다가 좀 헷갈리는게 있었다. @Mock, @MockBean 차이가 뭐지??? 쓰긴 하고 있는데 알고 써야 하지 않을까라는 의문이 들었다. 그래서 찾아봤다.

 

먼저 Mock 객체를 선언할 때에는 2가지 방법이 있다.

 

1. 첫번째 : mock() 을 이용해서 선언

 

1
2
3
4
5
6
7
8
9
10
11
12
@RunWith(MockitoJUnitRunner.class)
public class UserServiceTest {
 
    @InjectMocks
    private UserService userService;
    UserRepository userRepository = mock(UserRepository.class);
 
    @Test
    public void findByEmail_test(){
        when(userRepository.findByEmail("test@test.com")).thenReturn(Optional.of(new User()));
        userService.findByEmail("test@test.com");
        verify(userRepository).findByEmail("test@test.com");
    }
}
 cs

 

2. 두번째 : @Mock 을 이용해서 선언

 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
@RunWith(MockitoJUnitRunner.class)
public class UserServiceTest {
 
    @InjectMocks
    private UserService userService;
 
    @Mock
    private UserRepository userRepository;
 
    @Test
    public void findByEmail_test(){
        when(userRepository.findByEmail("test@test.com")).thenReturn(Optional.of(new User()));
        userService.findByEmail("test@test.com");
 
        verify(userRepository).findByEmail("test@test.com");
    }
}
 cs

 

이 2개의 테스트 케이스는 동일하게 동작한다. 

 

그리고 선언한 Mock 객체를 테스트를 실행하는 동안 사용할수 있게 하기 위한 작업이 있다. 바로 위에서 보이는 @RunWith(MockitoJUnitRunner.class) 가 바로 그 역할을 해준다.  또다른 방법으로는 아래와 같은 메소드를 테스트케이스 실행 전에 실행 시키면 된다. 

 

 

1
2
3
4
@Before 
public void initMocks() {
    MockitoAnnotations.initMocks(this);
}
 cs

 

여태껏 아무생각없이 둘다 @RunWith랑 initMocks랑 둘다 썼는데 둘다 쓸 필요가 없었다. ㅡㅡ;

 

그럼 @MockBean 은 뭐지??

 

@MockBean 은 Mock 과는 달리 org.springframework.boot.test.mock.mockito 패키지 하위에 존재한다. 즉 spring-boot-test에서 제공하는 어노테이션이다. Mockito 의 Mock 객체들을 Spring의 ApplicationContext에 넣어준다. 그리고 동일한 타입의 Bean  이 존재할 경우 MockBean으로 교체해준다.

 

그럼 언제 @Mock을 쓰고 언제 @MockBean 을 써야 하나??

 

결론적으로 Spring Boot Container가 필요하고 Bean이 container 에 존재 해야 한다면 @MockBean 을 쓰면 되고 아니라면 @Mock 을 쓰면 된다. 그런데 개인적으로는 그걸 잘 판단을 못하겠다.

 

1. MockitoJUnitRunner 를 이용해서 Mock을 사용한 Testcase.

 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
@RunWith(MockitoJUnitRunner.class)
public class RegisterControllerMockTest {
 
    @InjectMocks
    private RegisterController registerController;
 
    private ModelAndView model;
 
    @Before
    public void setup(){
        model = new ModelAndView();
    }
 
    @Test
    public void showRegistrationPage_test() throws Exception {
 
        registerController.showRegistrationPage(model, new User());
        Assert.assertEquals("register", model.getViewName());
    }
}
 
 cs

 

2. SpringRunner와 @WebMvcTest를 사용해서 @MockBean 을 사용한 Testcase

 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
@RunWith(SpringRunner.class)
@WebMvcTest(value = RegisterController.class, secure = false)
public class RegisterControllerTest {
 
    @Autowired
    private MockMvc mockMvc;
 
    @MockBean
    private UserService userService;
 
    @MockBean
    private EmailService emailService;
 
    @Test
    public void showRegistrationPage_test() throws Exception {
 
        mockMvc.perform(MockMvcRequestBuilders.get("/register"))
                .andExpect(status().isOk())
                .andExpect(view().name("register"))
                .andDo(print());
    }
}
 cs

분명 이 2개의 테스트 케이스 는 결과는 같지만 실제 내부에서 동작하는 부분은 다르다. 2번만 spring applicaiton context 가 올라간다. 그래서 부득이하게 @MockBean 으로 UserService 와 EmailService를 넣어줘야 했다. 1번은 Controller 객체에 대해서 Mock 을 만들어서 그거에 대해서만 테스트를 한다.(뭐라고 표현을 해야할지 잘 모르겠다.)

 

이렇게 같은 컨트롤러에 대한 테스트 이지만 작성하기에 따라서 여러가지 방법으로 테스트 케이스를 만들 수 있다. 아직은 미숙하지만 좀더 많이 작성하다 보면 방법도 많이 알게 되고 실제 구현 코드들의 모습도 많이 나아질거라는 생각이 든다.

 

참고 : https://stackoverflow.com/questions/44200720/difference-between-mock-mockbean-and-mockito-mock

728x90
반응형
저작자표시 비영리 변경금지

'Development > Java' 카테고리의 다른 글

[SpringBoot] Properties 우선순위  (0) 2018.06.07
[SpringSecurity]Spring Reference 수정  (0) 2018.04.21
[SpringBoot]Spring Boot Oauth login With Facebook 삽질기!!!  (0) 2018.03.04
작성중-[SpringBoot] ClassPathResource 의 getFile() 사용시 FileNotFoundException 발생  (0) 2018.01.12
[Spring-Data-JPA]Auditing을 추가해보자  (0) 2017.12.13
반응형

테스트케이스를 만들어서 작업을 하면 소스코드가 수정될 경우 코드를 테스트 해보기가 참 수월하다. 그런데 이 테스트 케이스 작성하는게 생각보다 만만치는 않다. 

실제 DB 를 읽어서 테스트를 해야 하는지. 아니면 Mock 객체를 정의를 해서 사용을 해야 하는지. 실제 DB 를 사용할 경우 저장된 data 가 변경이 되어서 구현했을 당시 테스트 케이스는 Pass였지만 나중에 빌드 시점에 테스트 케이스가 실행될 경우에 Fail 이 나면 어떻게 할것인지. 

생각해보면 그냥 서비스 구현해서 화면 띄우고 버튼 눌러서 테스트 하는것이 더 편할지도 모른다는 생각이 들기도 한다. 

작성할 때마나 서비스 테스트,  repository테스트, 컨트롤러 테스트에 대해서 구글링 하면서 작성을 하다보니 뭔가 남는게 없는것 같아서 샘플을 한번 만들어보기로 했다. 

 

최근에 필요하기도 했고 나중에 또 써먹을 일도 있을것 같아서 Controller 테스트 케이스를 작성한 것을 공유해 본다.

 

각각의 구성은 아래와 같이 되어있다. 

(java : 1.8, SpringBoot : 1.5.3)

 

Book.java

@Entity
public class Book {

    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private Long bookId;

    private String title;

    // Getter & Setter 생략
}

 

BookRepository.java

public interface BookRepository extends JpaRepository<Book, Long>{}

BookService.java

public interface BookService {
    Book getBook(Long id);
}
 

BookServiceImpl.java

@Service
public class BookServiceImpl implements BookService {

    @Autowired
    private BookRepository bookRepository;

    @Override
    public Book getBook(Long id) {
        return bookRepository.findOne(id);
    }
}
 

BookController.java

@RestController
public class BookController {

    @Autowired
    private BookService bookService;

    @RequestMapping(value = "/book/{bookId}", method = RequestMethod.GET, produces = "application/json")
    public Book getBook(@PathVariable Long bookId){
        return bookService.getBook(bookId);
    }
}

/book/{bookId} 라는 url 로 request 를 보내면 bookId 에 맞는 Book 객체를 리턴해주면 되는 형태이다. 테스트 케이스 없이 테스트 하려면 톰캣으로 띄워놓고 실제로 화면에서 위에 정의한 서비스를 호출하는 컴포넌트를 클릭해서 정상 동작을 하는지 확인해봐야한다. 그러다가 소스에 글자라도 하나 틀리면 수정한다음에 다시 톰캣 재기동을 하는 번거로운 작업을 진행해야 한다. 

 

 

 

 

 

 

 

 

 

 

이런 번거로움을 피하기 위해 테스트 케이스를 작성해 보았다.

@RunWith(SpringRunner.class)
@SpringBootTest
public class BookControllerTest {

    private MockMvc mockMvc;

    @MockBean
    BookController bookController;

    @Before
    public void setup(){
        mockMvc = MockMvcBuilders.standaloneSetup(bookController).build();
    }


    @Test
    public void getBookTest() throws Exception {
        given(this.bookController.getBook(new Long(1)))
                .willReturn(new Book("Homes"));

        mockMvc.perform(get("/book/{bookId}", 1))
                .andExpect(status().isOk())
                .andExpect(jsonPath("$['title']", containsString("Homes")))
                .andDo(print());
    }
}

BookController를  MockBean으로 정의를 해주었다. 그리고 BookController 의 getBook메소드에 파라메터가 1이 들어왔을 때 리턴 받는 결과를 미리 정의한다. (18~19 라인) 그리고 화면에서 요청하는 것처럼 Request를 수행해준다.  perform에 있는 파라메터를 보면 get 메소드를 호출하게 되며 파라메터로 1값을 넣어서 실행을 한다. OK 응답을 받게 되고 리턴 받는객체의 title이 "Homes"  인지 비교를 한다. 19라인에서 책 이름을 미리 Homes  로 정의 했기때문에 테스트는  Pass가 된다. 마지막에 andDo(print()) 는 실제 수행된 로그가 콘솔창을 통해 볼수 있도록 처리해 준것이다.

 

처음에 만들때는 좀 삽질을 하긴 했지만 만들고 보니 앞으로 자주 써먹을것 같다. 앞으로도 바쁘지만 테스트케이스를 만들면서 코드 작성을 하도록 해야겠다.

 

참고로 위 소스를 작성한 gradle.build 파일은 아래와 같다.

dependencies {
    compile('org.springframework.boot:spring-boot-starter-web')
    compile('org.springframework.boot:spring-boot-starter-data-jpa')

    runtime('group:com.h2database:h2');

    testCompile('group:com.jayway.jsonpath:json-path')

    testCompile('org.springframework.boot:spring-boot-starter-test')
}
 

 

728x90
반응형
저작자표시 비영리 변경금지

'Development > Java' 카테고리의 다른 글

[OAuth] Oauth의 간략한 흐름.  (0) 2017.07.04
[Spring Security]간단 Spring Security  (0) 2017.06.27
[Spring]Jasypt 를 이용한 properties 암호화  (6) 2017.04.25
[SpringCloud]Spring Config..  (0) 2016.01.26
spring Cache  (0) 2015.12.05

+ Recent posts

티스토리툴바