2007/01/07 14:55 Developer
JUnit Recipes
테스트의 중요성은 아무리 말해도 지나치지 않는다.
각자 중요하다고 생각하면서 테스트를 작성을 해봤겠지만, 이게 정말 안심하고 믿을수 있는 케이스인가에 대한 고민은 또 하나의 두려움에 봉착을 하게 된다.
작성한 코드를 refactoring을 통해서 디자인이나 알고리즘을 수정하고 난뒤 테스트 케이스만 실행해서 파란불이 나오면 그 코드를 어느정도 신뢰를 할수 있는것인가에 대한 문제는 케이스를 만들때의 또 하나의 어려움이다.
그 어려움을 극복하고자 JUnit Recipes를 보았다. 책이 두꺼워서 이 책만 보면 많은 영감을 얻을수 있고, 도움이 되겠지라는 생각에 처음부터 읽다가 책이 너무 방대해서 요령껏 다 읽었다. 하지만, 이 책은 너무 다양하게 다루어서 지금 내가 필요없는 부분도 많이 다루었다.
예를 들면 EJB테스트 같은 것은 정말 대충봤다. 테스트가 가능하긴 하구나라는 짧은 생각을 넘어갔다.
난 POJO에 대한 테스트를 더 원하고 있었기때문에 그것 위주로 보았고, 몇 개의 chapter에서는 많은 도움을 받았다. 아마 저자도 그런 생각으로 이 책을 쓰지 않았을까?
책을 보며서 느낀점은 테스트를 하고자 마음만 먹는다면 못 할것도 없다는 것과 테스트가 안된다고 얘기하는 것은 자기 코드를 잘못 짰다고 얘기하는 것 밖에 안되는 것이라는 생각이 들었다.
단위 테스트의 정말 중요한 관점은 깨지지 않아야 하고, 어디서나 실행이 가능해야 하고, 런타임시간이 짧아야 한다. 케이스의 나눌때의 요구사항이 명확해야 더 완벽한 케이스를 만들수가 있다.
Test Code와 Production Code는 하나여야 한다. 테스트할 수 있는 코드를 작성하다가 보면, 좀더 좋은 디자인으로 OOP에 가까운 개발을 할수가 있을 것이다.
더 신뢰성 있는 코드를 작성하기 위해서 이 책으로 부족한 부분을 채우는 것이 어떨까?
각자 중요하다고 생각하면서 테스트를 작성을 해봤겠지만, 이게 정말 안심하고 믿을수 있는 케이스인가에 대한 고민은 또 하나의 두려움에 봉착을 하게 된다.
작성한 코드를 refactoring을 통해서 디자인이나 알고리즘을 수정하고 난뒤 테스트 케이스만 실행해서 파란불이 나오면 그 코드를 어느정도 신뢰를 할수 있는것인가에 대한 문제는 케이스를 만들때의 또 하나의 어려움이다.
그 어려움을 극복하고자 JUnit Recipes를 보았다. 책이 두꺼워서 이 책만 보면 많은 영감을 얻을수 있고, 도움이 되겠지라는 생각에 처음부터 읽다가 책이 너무 방대해서 요령껏 다 읽었다. 하지만, 이 책은 너무 다양하게 다루어서 지금 내가 필요없는 부분도 많이 다루었다.
예를 들면 EJB테스트 같은 것은 정말 대충봤다. 테스트가 가능하긴 하구나라는 짧은 생각을 넘어갔다.
난 POJO에 대한 테스트를 더 원하고 있었기때문에 그것 위주로 보았고, 몇 개의 chapter에서는 많은 도움을 받았다. 아마 저자도 그런 생각으로 이 책을 쓰지 않았을까?
책을 보며서 느낀점은 테스트를 하고자 마음만 먹는다면 못 할것도 없다는 것과 테스트가 안된다고 얘기하는 것은 자기 코드를 잘못 짰다고 얘기하는 것 밖에 안되는 것이라는 생각이 들었다.
단위 테스트의 정말 중요한 관점은 깨지지 않아야 하고, 어디서나 실행이 가능해야 하고, 런타임시간이 짧아야 한다. 케이스의 나눌때의 요구사항이 명확해야 더 완벽한 케이스를 만들수가 있다.
Test Code와 Production Code는 하나여야 한다. 테스트할 수 있는 코드를 작성하다가 보면, 좀더 좋은 디자인으로 OOP에 가까운 개발을 할수가 있을 것이다.
더 신뢰성 있는 코드를 작성하기 위해서 이 책으로 부족한 부분을 채우는 것이 어떨까?
