. Spring의 도움으로 의존성을 해결했다!음.. 그런데 이전에 모든 작업을 직접 코딩할 때는 autoCommit 속성을 이용하여 트랜잭션 관리를 하면 됐는데 (false, true 변환)지금은 직접 핸들링 할 수 가 없다.. INSERT는 어떻게 테스트 할까... DELETE를 직접 해줘야 되나... !!! @TransactionConfiguration(transactionManager = "transactionManager", defaultRollback = true) 위의 Annotation을 테스트 클래스 상단에 붙이고@Transactional Annotation을 사용하면 하나의 트랜잭션으로 관리되고 롤백처리된다....
. 1. 문제점 - Spring을 사용하여 DB 연동에 관한 코드를 처리하였는데, DB 테스트를 하자니 Bean 생성부터 되질 않으니 테스트에서 DataSouce 객체부터 코딩해야하는 불편함 2. 해결- Spring의 테스트 관련 기능 사용- 다음과 같은 Annotation을 테스트 클래스 상단에 붙임- @RunWith(SpringJUnit4ClassRunner.class)- @ContextConfiguration(locations = {"classpath:spring/test-applicationContext.xml"})- 여기서 classpath 대신 '/' (root)를 사용해도 ok- 이렇게 Spring 의존성을 해결하고 @Autowired로 원하는 객체에 DI하고 테스트...
테스트소스만 간단히 보게되면 다음과 같다.미완성 버전이고 아직 이걸 어떻게 활용해야할지 감은 안오지만,단순하면서도 강력한 기술이라고 생각한다. 켄트벡은 책에서 파이썬 버전의 xunit을 예제로 사용했는데나는 자바를 좋아하므로 자바버전으로 개발해보았다. 자바에는 리플렉션이란 훌륭한 기술이 있어서파이썬버전과 동일하게 구현하였다... package xunit; import static xunit.AssertionModule.*; public class TestCaseTest extends TestCase { TestCaseTest(String methodName) {super(methodName);} public void testTemplateMethod() {TestResult result = new Tes..
. [25장. 테스트 주도 개발 패턴] - 테스트 한다는 것은 무엇을 뜻하는가?- 테스트를 언제 해야 하는가?- 테스트할 로직을 어떻게 고를 것인가?- 테스트할 데이터를 어떻게 고를 것인가? 고민해보자.. |’테스트할 시간이 없다’의 죽음의 나선|많은 작업량으로 인해 스트레스가 증가하면 테스트를 점점 더 뜸하게 한다. 테스트를 뜸하게 하면 프로그램의 에러는 점점 많아질 것이고, 에러가 많아지면 더 많은 스트레스를 받게 된다. 이를 해결하기 위해서는 테스트를 작성하고 실행해야 한다. 하지만, 그 동안 미뤄왔던 일이 쉽게 해결되지는 않는다. 이렇게 죽음의 나선은 반복적으로 순환하며 프로그래머를 괴롭힌다. 자동화 테스트는 귀찮은 작업이지만, 작업 결과에 대한 신뢰성을 높여주고, 테스트의 실패에 대한 부담감을 ..
화폐 예제 $5 + 10CHF = $10설계의 완벽함보다 동작하는 코드가 우선이다.우선 동작하는 코드를 작성한 뒤에 리팩토링을 통해 설계를 보완한다.TDD를 통해 잘 동작하는 깔끔한 코드를 작성하자. Unit Test (단위 테스트)unit 미국·영국 [|ju:nɪt] 영국식 다른 뜻(1건) 예문보기1. 구성 단위 2. (상품의) 한 개 3. (특정 임무를 위한) 부대unit test란 단어대로 프로그램의 작은 부분(모듈) 하나를 테스트하는 것을 말한다.주로 하나의 method(function)가 대상이 되며 사내에서는 Branch coverage를 적용 test는 어떤 상황에서도 초록막대를 유지해야하기 때문에 외부 환경에 의존적인 코드는 지양하거나, 그에 대한 의존성을 제거한다.의존성 제거를 위해서 M..
새로운 지식이나 기술을 익히는데 있어서 실습만큼 좋은 것은 없겠지만, 기술에 대한 정의를 곱씹어보거나, 왜? 라는 질문을 해보는 것도 중요하다고 생각한다.켄트 벡은 단순하지만, 중요한 두 가지 법칙을 제시한다. 1. 어떤 코드건 작성하기 전에 실패하는 자동화된 테스트를 작성하라. 2. 중복을 제거하라.즉 테스트를 작성하며 개발하고, 보기 좋은 코드를 짜라는 이야기인 것 같다. 용어는 확실치 않지만, 테스트 주기라 부르는 작업이 있다.1. 실패하는 테스트(빨간 막대)를 작성하고 2. 테스트가 성공하도록(초록막대) 최대한 빠르고, 단순하게 에러를 처리한다. 3. 중복을 제거(리팩토링)위와 같은 작업을 반복하는 것을 우리는 TDD라 부른다. 듣기로, 테스트 주기는 짧은 것이 좋다고 했던것 같다. 실제 프로젝트..
mock 미국식 [mɑ:k] 영국식 [mɒk] 다른 뜻(2건) 예문보기1. (특히 흉내를 내며) 놀리다 2. 무시하다 3. 거짓된, 가짜의 소프트웨어에서 Mock 객체는 실제 모듈과 비슷하게 보이도록 만든 가짜 객체를 말한다. Mock 객체를 활용하면 모듈 간의 의존성에 구애받지 않고 테스트 케이스를 작성하고 TDD를 수행할 수 있다. 언제 Mock 객체를 만들 것인가? 1. 테스트 작성을 위한 환경 구축이 어려워서 2. 테스트가 특정 경우나 순간에 의존적이라서 3. 테스트 시간이 오래 걸려서 오늘은 이정도만 하고 마치도록 한다. 출처 : 한빛미디어, 테스트 주도 개발 고품질 쾌속개발을 위한 TDD 실천법과 도구, 채수원 지음