개발 cs지식 스터디를 하며 내가 학습한 부분을 정리하는 공간입니다.
테스트 기반 개발 - 한 번에 한 걸음씩 우물을 파는 것과 같습니다.
TDD란 Test Driven Development의 약자로 '테스트 주도 개발'이라고 한다.
설계 이후 코드 개발 및 테스트케이스를 작성하는 기존의 개발 프로세스와는 다르게
테스트 케이스를 작성 한 후 실제 코드를 개발하여 리펙토링 하는 절차를 따른다.
이러한 이유로 TDD를 Test First Development라고 부른다.
TDD는 작가가 책을 쓰는 과정과 유사하다.
목차를 처음 구상하고 목차에 맞는 내용을 고쳐쓰기를 반복한다.
반복적인 검토와 고쳐쓰기를 통해 좋은 글이 완성되는 것처럼
소프트웨어도 반복적인 테스트와 수정을 통해 고품질의 소프트웨어를 만들 수 있다.
일반적인 개발 방식과 TDD의 가장 큰 차이는
테스트 코드를 작성한 뒤에 실제 코드를 작성한다는 점이다.
디자인(설계) 단계에서 프로그래밍 목적을 반드시 미리 정의해야만 하고,
또 무엇을 테스트해야 할지 미리 정의(테스트 케이스 작성)해야만 한다.
테스트 주도 개발(Test-Driven-Development, 이하 TDD)의 저자
켄트 벡 - “테스트 없이 프로그래밍하면 확신이 덜 생기고 시간은 더 걸린다.”
개발하는중 코드를 많이 바꿔야 된다고 생각하는 경우
개발하고 나서 이 코드를 누가 유지보수할지 모르는 경우
즉 ! 불확실성이 높을때 TDD를 하면 된다.
디버깅 시간을 단축
코드가 내 손을 벗어나기 전 가장 빠르게 피드백을 받을 수 있다.
(기능 단위로 테스트를 진행하기 떄문)
작성한 코드가 가지는 불안정성을 개선하여 생산성을 높일 수 있다.
재설계 시간을 단축(게임에서 말하는 Life를 비축한 느낌)
추가 구현이 용이
코드량이 늘어난다 => 생산성의 저하 =>
빠른 생산성이 요구되는 시점에서는 큰 걸림돌이 된다.
(기존의 비즈니스 로직, 각종 코드 디자인 + 테스트 코드 작성)
주객전도
실제 코드가 더 중심이 되어야 하는데,
테스트를 위해 코드의 구조를 바꿔야하나 고민이 생긴다.
발생할 수 있는 상황에 대한 코드를 작성하기 위해 배보다 배꼽이 더 커진다.
Summary
다양한 사용자가 존재하며, 생각지도 못한 예외 케이스가 존재할 수 있다.
테스트를 반드시 해야 하는 부분에 있어서 테스트 코드를 작성하는데
여러 난관이 겪는다면?
모든 코드에 대해서 테스트 코드를 작성할 수 없으며 작성할 필요도 없다.
또한 테스트 코드를 작성한다고 해서 버그가 발생하지 않는 것도 아니다!
디자인패턴 중 하나로 MVC(Model-View-Controller)는 사용자 인터페이스, 데이트 및 논리 제어를 구현하는데 널리 사용되는 디자인 패턴이다.
소프트웨어의 비즈니스 로직과 화면을 구분하는데 중점을 두고 있다.
User가 Controller를 조작하면 Controller는 Model를 통해서 데이터를 가져오고, 그 정보를 바탕으로 View를 시각적 표현을 제어하여 사용자에게 전달한다.
애플리케이션의 정보, 데이터를 나타낸다.
DB, 처음 정의하는 상수, 초기화값, 변수 등을 뜻하며 또한 이러한 데이터와 정보들의 가공을 책임지는 컴포넌트를 말한다.
input text, checkbox 등 사용자 인터페이스 요소를 나타낸다.
즉, 데이터 및 객체의 입력, 보여주는 출력을 담당한다.
(데이터를 기반으로 사용자들이 볼 수 있는 화면)
사용자가 접근한 URL에 따라 사용자의 요청사항을 파악 ->
그 요청에 맞는 데이터를 Model을 의뢰 ->
데이터를 View에 반영 -> 사용자에게 알려준다.
즉, 데이터와 사용자인터페이스 요소들을 잇는 다리 역할을 한다.
사용자가 데이터를 클릭하고, 수정하는 것에 대한 "이벤트"들을 처리하는 부분이다.
사용자가 보는 페이지, 데이터처리 그리고 이 2가지를 중간에서 제어하는 컨트롤
이 3가지로 구성되는 하나의 애플리케이션을 만들면 각각 맡은바에만 집중을 할 수 있게 된다. (ex. 공장의 분업화)
서로 분리되어 각자의 역할에 집중할 수 있게끔해 애플리케이션을 만든다면
유지보수성, 애플리케이션 확장성, 유연성이 증가하고 중복코딩이라는 문제점 또한 사라진다.
유연성 : 클라이언트의 새로운 요구사항에 대한 최소한의 비용으로 대체
Model - 백그라운드에서 동작하는 비즈니스 로직(데이터) 처리
View - 정보를 화면으로 보여주는 역할
Controller - 사용자의 입력 처리와 흐름 제어 담당.
화면과 Model과 View를 연결시켜주는 역할
결국 "어떻게 나눌 것인가" 에 대한 해답 중 하나이다.
어떤 특정한 역할들에 대해 역할분담을 할 때 가이드라인을 제시하는 방법중 하나가 MVC패턴
이다.