TDD

Spring WebFlux와 Kotlin으로 만드는 Todo 서비스 – 1편 Spring WebFlux와 Kotlin으로 만드는 Todo 서비스 – 2편 Spring WebFlux와 Kotlin으로 만드는 Todo 서비스 – 테스트 슬라이스 적용하기 개요 지난 예제들에선 간단한 Todo 예제를 만들고 개선해봤습니다.  또한 그렇게 만들어진 예제의 CRUD를 curl을 이용해 동작을 검증하였습니다.  하지만 변경 사항이 발생하였을 경우 매번 애플리케이션을 재기동 하여 잘 동작하는지 확인해야 했고 각각의 모듈이 어떤 기능을 하는지 알기 어려웠으며, 정상 수행에 대한 피드백을 빠르게 얻기 힘들었습니다. 물론 현재는 작은 규모의 프로젝트이지만 나중엔 기능을 추가하고 안정성을 강화해 프로덕션 규모의 큰 애플리케이션으로 바뀔 수도 있습니다. 이런 경우엔 테스트를 효율적으로 작성하는 전략이 중요해집니다. 이번 편에선 지난 예제를 기반으로  테스트를 작성해보면서 Spring Boot에서 지원하는...

원문 : https://gregor77.github.io/2019/08/16/about-unit-test/ 관련글 : https://www.popit.kr/unit-test-단위-테스트-도입하기-1편/ 이전글에서 단위 테스트의 장점과 도입하기 전에 궁금증에 대해서 알아봤다. 이제 단위테스트를 도입할 준비가 되었다면 이번글은 단위테스트 시작 시에 참조할 만한 작성 기준과 지속하기 위한 방법에 대해서 알아보겠다. 꼭 이렇게 할 필요는 없으며, 가장 중요한 것은 팀원 모두가 합의한 방식으로 시작하면 되고, 지속하는 과정중에 불편한 점이 있으면 언제든지 개선해서 적용하는 과정을 반복한다면 팀에 단위테스트 문화를 성공적으로 정착시킬 수 있을 것이다...

원문 블로그 주소 : https://gregor77.github.io/2019/08/16/about-unit-test/ 관련글 : https://www.popit.kr/unit-test-단위-테스트-도입하기-2편/ 지금 부서의 역할이 사내에서 제품을 가지고 있는 팀들과 협업을 하면서 기존에 문제를 해결하고 사용자 관점에서 더 가치있는 제품을 항상 딜리버리 가능한 상태로 만드는 것을 목표로 하고 있다. 기존의 문제를 해결하는 방법으로 Agile의 Practice를 필요에 따라 활용하고 있으며, 특히 개발 Practice로는 TDD, Unit Test, Code Review, Pair Programming, CI/CD 자동화, Build Monitor 등의 프랙티스를 가져간다. 개발자로써 프로젝트를 진행하면서 TDD까지 전파하는 것은 정말 어려운 일이고, TDD까지 가기전에 Unit Test 작성하는 것을 우선적으로 전파하려고 하는 편이다. 테스트케이스 작성하는 방법을 체득화하고 그 이후에 TDD까지 이어가려고 하는데, TDD를 하기위해서 개발습관이나 사고방식이 함께 바껴야 하기 때문에 팀에 체득화 시키는 것은 항상 쉽지 않았다. TDD에 대해서는 할말이 ...

해당 코드는 Github 에 공개되어있습니다. Spring Guide Test 전략 가이드 Exception 전략 가이드 Domain 객체 가이드 외부 API 가이드 Service 적절한 크기 가이드 스프링은 다양한 테스트 전략을 제공하고 있습니다. 대표적으로 Slice Test 라는 것으로 특정 레이어에 대해서 Bean을 최소한으로 등록시켜 테스트 하고자 하는 부분에 최대한 단위 테스트를 지원합니다. 다양하게 지원해주는 만큼 테스트 코드를 통일성 있게 관리하는 것이 중요합니다. 더 안전하고 통일성 있게 테스트를 진행하는 방법에 대해서 제 나름의 노하우를 정리해보았습니다....

이전 포스팅 BDD(Behaviour-Driven Development)에 대한 간략한 정리에서 같이 다루려고 했던 내용이다. 하나의 클래스를 테스트하기 위해서는 그 클래스가 사용하는 다른 클래스의 실제 구현이 필요하거나 테스트 대상 클래스가 사용하는 데이터베이스 등에 대한 외부 환경이 구성되어 있어야 하는 경우가 있다. 하지만 테스트 환경에서 이를 모두 구성하는 것은 현실적으로 쉽지 않고, 테스트 실패에 대한 원인이 해당 클래스만의 문제인지, 아니면 관련된 다른 클래스의 문제인지를 찾기가 무척 어렵다. 즉, 테스트 대상 클래스의 기능만 한정 지어 테스트를 수행하기 어려운 경우가 많다. 테스트 용이성이란 말 그대로 테스트 대상을 얼마나 테스트하기 쉬운가에 대한 척도이다. 테스트 대상이 얼마나 복잡한가? 얼마나 결합도가 높은가? 등 몇 가지 내용이 있지만, 이번 글에서는 테스트 용이성에서 결합도와 Mocking 에 대한 내용만을 간단히, 이를 개선하기 위해 Dependency Injection 이 어떻게 사용되는지에 대해 설명한다. 이 글에서 Mocking 은 Mocking 객체를 의미하며 이를 간단히 말하면 실제 객체를 흉내내는 가짜 객체를 하나 만드는...

단위 테스트는 단순히 테스트 코드가 아니라 리펙토링을 위한 안전망이며 코드를 설명하는 문서 역할도 한다....

* 이 글은 여전히 직접 개발하는 수석 기술자 [1] Evan Bottcher 가 ThoughtWorks 블로그에 올린 What are our core values and practices for building software? 을 번역한 글입니다. 올해 들어, 소트웍스에서 개발자로 근무하면서 내 경력과 인생에서 어떤 의미가 있는지 많이 생각하게 되었다. 그 중에는 훌륭한 사람들과 함께 일하는 점이 돋보인다. 그들은 신뢰와 정직은 기본이고, 소프트웨어 산업 증진에 필요한 추진력도 골고루 갖추고 있다. 소프트웨어를 구축하는 기술을 보면, 우리 회사에서 통하는 근본적인 소프트웨어 공학 가치는 여느 열정 있는 개발자 커뮤니티에서도 통용된다. 그러한 핵심 가치와 그것을 지원하는 실천사항에는 어떤 것이 있는지 밝히고자 이 글을 쓴다....