취대넓얕

[기술면접] 4일차 문답 | FBV CBV 테스트코드 TDD

째깍단 2023. 7. 24. 11:01

 

FBVCBV는 각각 무엇이며, 어떤 차이가 있습니까?

Function-Base Views  함수 기반 뷰

함수기반 뷰는 뷰를 작성할때 함수로 작성하는 방식

# views.py

@api_view([‘GET’, ‘POST’])
def index(request):
    if request.method == ‘POST’:
        return HTTPResponse(“post method”)
    if request.method == ‘GET’: #else:
        return HTTPResponse(“get method”)

 

 

Class-Based Views  클래스 기반 뷰

클래스 기반뷰는 클래스 형식으로 작성하는 방식

From django.views import View

Class NewView(View):
    def get(self, request):
        return HTTPResponse(“get method”)
    def post(self, request):
        return HTTPResponse(“post method”)

 

두 방법은 클래스/함수 구현의 로직만 다를뿐 같은 기능을 한다.

 

 

 

함수기반 뷰의 장단점


+ 편하게 구현할 수 있고 읽기 편한 로직을 가진다

+ 데코레이터의 사용이 명료하다


- 확장성 / 재사용성이 떨어진다

 

 

클래스 기반 뷰의 장단점

+ 확장과 재사용이 용이하다

+ 다중상속이나 Mixin이 가능하다

+ HTTP method가 클래스 안에서 나누어서 처리됨

+ 강력한 generic view 지원

 

- 읽기 어려울 수 있음

- 상속, mixin으로 코드이해를 위해 숨은 코드를 찾아보아야함

- 뷰 데코레이터를 사용하려면 따로 import를 하거나 메소드를 오버라이드 해야함

 

 

따라서, 상속이나 재사용이 많이 필요한 프로젝트의 경우 CBV 그렇지 않은 경우에는 FBV를 활용하면 좋다!

 

 

 

 

*** Mixin 이란?

객체 지향 프로그래밍 언어에서 믹스인(mixin 또는 mix-in)

프로그래머가 특정 코드를 다른 클래스에 삽입 할 수 있도록 하는 프로그래밍 개념으로,
다른 클래스의 부모클래스가 되지 않으면서 다른 클래스에서 사용할 수 있는 메서드를 포함하는 클래스이다.

 

 

1) 여러 클래스가 공용기능들을 사용할 수 있게 하는 다중상속의 메커니즘을 제공

2) 코드재사용성 : 믹스인은 프로그래머가 서로 다른 클래스간에 기능을 공유하고자 할 때 유용함
     동일한 코드를 반복해서 작성하는 대신 공통기능을 믹스인으로 그룹화하고 이 기능을 필요로하는 다른 클래스들에 추가할 수 있다

3) 믹스인은 부모클래스의 모든 기능을 상속하지 않고 필요로 하는 기능만 상속하고 사용할 수 있다.

 

[참조] : https://ko.wikipedia.org/wiki/%EB%AF%B9%EC%8A%A4%EC%9D%B8

 

 

 

 

 

테스트코드를 작성하는 이유는 무엇이며 어떤 장점이 있습니까?

1) 코드의 로직을 이해해야 작성이 용이하기때문에 작성하는 것만으로도 코드의 구조를 이해하는데에 도움이 된다

2) 구현한 기능의 보이지 않는 오류를 테스트코드를 통해 검증하고 찾아내어 보완할 수 있다

3) 코드 변경 시, 변경 부분으로 인한 영향도를 쉽게 파악할 수 있다.

4) 코드 리팩토링 시 기능 구현이 동일하게 되었다는 판단을 내릴 수 있다.

5) 구현한 코드의 정확도를 확인할 수 있다

6) 프론트엔드 작업자가 백엔드 작업에서의 오류를 쉽게 확인할 수 있게 해주어 협업에 용이하다

 

 

 

 

 

절차 : * 테스트 코드 작성하는 시간까지 계산해서 프로젝트 개발 소요 시간을 계획해야함

  • 요구사항(함수와 구현 기능, 성능, UI, API 스펙)에 따라서 다양한 테스트가 있다.
  • Python manage.py test 명령어로 실행할 수 있고,
    test뒤에 어플리케이션 명을 입력해 각 어플리케이션의 test를 진행할 수도 있다.
  • 모든 테스트가 패스되면 완성되었다 할 수 있고, Fail테스트는 Modify or fix 해야한다.
  • 항상 실패없이 실행되도록 유지해야하며, 정기적인 빌드를 통해 테스트가 실패하는 케이스를 찾아낸다

 

 

 

종류 : UI test, Integration test, Unit test

 

단위테스트 / 통합테스트 / UI테스트로 구분할 수 있음

[자세한 내용은] https://hanamon.kr/%ED%85%8C%EC%8A%A4%ED%8A%B8-%EC%BD%94%EB%93%9C-%EC%9E%91%EC%84%B1%EC%9D%98-%EC%A4%91%EC%9A%94%EC%84%B1/


 


TDD(테스트 주도 개발)란?  Test-driven development

개발 방식, 방법론 중 하나로 개발(코드 작성)전 테스트 코드를 먼저 작성하는 것

 

방법

  • 케이스 단위로 테스트를 기능 구현 전에 작성한다
  • 작성 과정에서 예외 케이스를 생각해야 한다
    케이스 별로 실제 행위 유발: 직접적으로 함수를 불러 호출 / 커맨드로 간접 호출
  • 행위의 결과 확인: pass/fail
  • 케이스 자동화

 

장점 

  • 설계자의 관점에서의 개발이 가능 = 협업에 용이
  • 요구사항이나 목표를 점검할 수 있고, 사용자 입장에서 코드를 작성할 수 있다
  • 테스트 통과율이 높아진다
  • 오버 엔지니어링을 방지한다.