-
테스트코드에서 setup 함수와 setupclass 의 차이는 무엇입니까?
장고에서 테스트를 할 때 테스트 DB를 생성하고, 모든 테스트 메서드를 실행할 때매다 장고는 DB를 초기화합니다.
unit-testing 원칙은 모든 테스트는 서로 독립적이어야한다는 뜻입니다. A 테스트에 의존에서 B 테스트를 하는 건 옳지 않습니다.
독립성을 유지하면 회원가입 테스트 후 로그인 테스트를 할 때, 회원가입 테스트에서 생성한 유저를 가져올 수 없습니다. 그렇기에 회원가입 후 로그인하는 테스트를 만들어줘야 하는데, 이렇게 매번 데이터를 생성하고 테스트 하는 건 번거롭습니다.
그럴 때 사용하는 것이 setup과 teardown 입니다. setup은 클래스 내에서 정의된 모든 테스트 메서드 이전에 실행되고, teardown은 모든 테스트 메서드 마지막에 실행됩니다.
setUp() 메서드는 각 테스트 메서드가 실행되기 전에 매번 호출됩니다. 테스트가 많아지게 되면, 같은 데이터를 사용하면서 setUp() 메서드를 계속 호출하는 것은 비효율적입니다.
setUpClass()는 해당 테스트 클래스를 실행할 때 한 번만 호출이 됩니다. 한 테스트 클래스 내에서 각 테스트 메서드가 모두 같은 데이터를 사용할 때, setupclass로 만들어주면 속도면에서 더 효율적입니다.
Template Engine을 사용할 때, 발생하는 CSRF Error가 무엇이고 어떻게 해결합니까?
크로스 사이트 요청 위조(CSRF)는 인증된 사용자가 웹 애플리케이션에 특정 요청을 보내도록 유도하는 공격 행위를 말합니다. 크로스 사이트 요청 위조는 생성된 요청이 사용자의 동의를 받았는지 확인할 수 없는 웹 애플리케이션의 CSRF 취약점을 이용합니다. 공격자의 요청이 사용자의 요청인 것처럼 속이는 공격 방식이기에 크로스 사이트 요청 위조라는 명칭이 붙었습니다.
크로스 사이트 요청 위조는 사용자가 인증한 세션에서 웹 애플리케이션이 정상적인 요청과 비정상적인 요청을 구분하지 못하는 점을 악용하는 공격 방식으로, 웹 애플리케이션이 사용자의 요청이 실제 사용자가 전송한 것인지 확인하지 않는 경우에 자주 발생합니다.
이런 공격을 막고자 Django에서는 CSRF 보호 기능이 활성화되어 있습니다. CSRF Error는 이 기능 덕분에 신뢰할 수 없는 호스트를 차단해주어 나오는 오류입니다. 이 오류를 해결하는 방법으로는
- 템플릿의 form 태그에 {% csrf_token %}를 추가해주는 방법
- 뷰 함수에 @csrf_exempt 데코레이터를 씌워주는 방법. 이 방법은 CSRF 보호 기능을 비활성화 시키는 방법으로 보안상 권장되지 않습니다.
- settings.py의 CSRF_TRUSTED_ORIGINS에 호스트를 추가하는 방법
참고: