테스트(+걍 제일 쉬운 걍 예상되는 시나리오케이스 나열) > 코딩 > 리팩토링

#왜 테스트를 자동화?

웹서버api 구현시 

put > get > delete 이 과정을 거의 반복해서 잘 입력되나, 잘 꺼내오나, 잘 삭제되나.. 테스트하게 된다.  심지어 파라미터가 많은 경우에는 너무 많은 성공조건이 생긴다. 

( &ids=&version=&blabla=&foo=....)

이런 케이스말고 에러를 뱉어야 하는 케이스도 있다.

중간에 리팩토링 하는 과정도 있다. 그럼 그때마다 위에 케이스를 다 테스트한다고 하면.. 테스트하는시간이 겁내 많이 걸릴거 같아 좀 힘들거 같다... 동일한 입력포맷에 대해 예상하는 아웃포맷에 대한 테스트를 자동화 하면, 넘나 시간을 단축시킬수 있다.

코딩 > 테스트 > 리팩토링

보다는

테스트(+걍 제일 쉬운 걍 예상되는 시나리오케이스 나열) > 코딩 > 리팩토링 !

테스트코드를 나의 손가락과 시나리오케이스를 좀더 깊게 생각해볼수 있게 도와주고 있다고 생각한다. 코드작성에만 좀더 신경쓸수 있게 해준다는 거지.. 

• 반복되는 테스트나 (CRUD....)
• 에러처리 등 예외발생 케이스에 대한 시나리오

#테스트범위는 어떻게 나눌까?

controller -> service -> dao

컨트롤러입장에서는 service 만 있으면 되는데, service 가 있으려면 디비가 있어야 되고.. 그렇다는 얘기는 dao도 있다는 얘기고.. 

의존해야 하는 대상이 있다면 mock 으로대체.. mock 객체도 만들어 줘야됨

mock객체를 생성해주는 라이브러리로 mockito..

• 레이어로 나눠서 단위테스트를 작성하고
• controller ~ dao 합쳐서 통합테스트를 작성하고

테스팅자동화에 도움을 주는 프레임워크를 잘 쓰고 있냐고 하면 ?

나는 잘모르겠다. 라고 말할거 같다.. 

mock객체로 테스트코드를 만드는것 보다 실제 객체로 만드는게 아직은 더 익숙하기 때문인거 같다.  

그런데 많이 늘었구나..라고 생각드는 부분은 

• 예외케이발생에 대한 시나리오를 생각 하는것과
• 리팩토링을 자주 할수 있다는 심적위안?  인거 같다.
• 테스트메소드의 작명을 하면서 메소드명이 겁내 길었다가 딱! 맘에 들게 = 메소드명으로도 뭐하는 애지 알수있게 만들면, 네이밍하는것도 늘었나 라는 생각이들기도 하고 ㅎㅎ
• 너무 역할을 많이 주었나? 라며 클래스를 빼기도 하고 .. 메소드를 좀 잘게 나눠보기도 하고.. 맞게 잘 나눠진거 같으면 기분도 좋고..
• 리팩토링이 신경을 좀더 쓰는 코드를 만들게 되면 .. 오..  TDD 나도 이제 좀더 큰건가.. 싶기도 하고..