728x90

파이썬 장고가 제공하는 단위 테스트는 코드 배포전에 에러를 검출해 볼 수 있는 방법으로 무척 유용합니다. 젠킨스 빌드시에도 활용하여 자칫 로컬 환경과 원격 빌드/운영 환경의 차이에도 대응할 수 있어 장애를 막는 지름길이 되기도 합니다.

파이썬 장고의 단위 테스트를 구성해서 잘 사용하던 중, 갑자기 (원인은 알 수 없습니다 ㅜㅜ) TransactionManagementError와 함께 테스트가 지속적으로 실패하기 시작하여 열심히 구글링하고 삽질한 내용을 간략히 정리해 봅니다. 


장고 단위 테스트를 사용하기 위해서는 아래와 같은 코드를 만들게 됩니다. 참고로 코드는 장고 공식 문서에서 가져왔습니다. 이때, 실제 테스트를 수행하는 클래스는 매개변수로 TestCase 클래스의 인스턴스를 받게 됩니다. 아래의 코드에서는 TestCase 클래스를 가져왔네요.

import unittest
from django.test import Client

class SimpleTest(unittest.TestCase):
    def setUp(self):
        # Every test needs a client.
        self.client = Client()

    def test_details(self):
        # Issue a GET request.
        response = self.client.get('/customer/details/')

        # Check that the response is 200 OK.
        self.assertEqual(response.status_code, 200)

        # Check that the rendered context contains 5 customers.
        self.assertEqual(len(response.context['customers']), 5)

 

코드를 보면 실제 테스트 함수들이 클래스 내에 기술이 되어 있습니다. 제 경우 문제는 테스트 함수들이 데이터베이스에 대한 질의를 수행하는 코드를 호출하면서 발생했습니다. 일반적인 TestCase의 서브 클래스로는 데이터베이스 관련 코드를 수행하고 테스트 결과를 돌려주는데 문제가 있었습니다. 테스트가 수행되면서 발생한 에러는 아래와 같습니다.

raise TransactionManagementError(
django.db.transaction.TransactionManagementError: An error occurred in the current transaction. You can't execute queries until the end of the 'atomic' block.

 

이 에러 메세지가 참 얄미운게 내용이 좀 뭉뚱그려져 있습니다. 굉장히 명확한 에러이기 때문에 TestCase 클래스를 트랜잭션을 지원하는 것으로 변경하라고 하면 되었을 것을 저렇게 표현하고 있어서 애를 먹게 만들더군요. 이 문제에 대한 첫번째 접근은 장고 공식문서에서 가이드하는 TransactionTestCase 클래스의 사용입니다. 

https://docs.djangoproject.com/en/3.2/topics/testing/tools/#django.test.TransactionTestCase

 

제 경우는 장고 REST Framework 를 사용하고 있던 관계로 이쪽에서 필요한 클래스의 변경 작업을 진행했습니다. 기존에 에러가 발생하던 테스트 코드에서는 REST Framework가 제공하는 test 패키지의 APITestCase 클래스를 쓰고 있었습니다. 이 클래스를 APITransactionTestCase로 변경하니 에러가 말끔히 사라지고 테스트도 정상적으로 수행되기 시작했습니다.

# 기존
from rest_framework.test import APITestCase

# 변경
from rest_framework.test import APITransactionTestCase

 


TransactionManagementError로 검색을 하다보면 여러가지 문제 상황과 이에 대한 대처법들이 소개되고 있습니다. 가령 1) 테스트 테이블에 데이터를 피딩하는 과정에 문제였고 이를 수정하여 해결 했다는 분도 계셨고, 2) 테스트가 수행하는 코드 내에 try~except 구문이 사용되는 경우 transaction.atomic() 을 이용해서 코드를 변경해야 된다는 글도 있었습니다.

다양한 트러블슈팅 사례와 방법이 있는 것을 보면 에러 메세지가 조금 더 친절하게 출력되면서 원인을 빠르게 확인할 수 있었으면 어땠을까 하는 생각이 듭니다. 그래도 트러블슈팅을 하면서 또 파이썬에 대해, 장고에 대해 조금 더 알 수 있었기에 의미 없는 시간은 아니었던 것 같습니다!

파이썬과 관련하여 최근에 겪었던 다른 이슈들과 해결 방법은 아래의 글을 참고해 보시기 바랍니다!

 

M1 Apple silicon 맥북에서 파이썬 cryptography 패키지 설치가 안되는 문제 / python cryptography package installa

M1 silicon 맥북에서는 안되는게 참 많습니다. 새로운 CPU 아키텍쳐라서 여기저기서 패키지들이 오동작하거나 설치가 안되는 문제들이 많이 발생합니다. 오늘의 주인공인 파이썬 cryptography 패키지

ondemand.tistory.com

 

 

애플실리콘 M1 맥북에서 파이썬 magic 패키지가 로딩되지 않는 현상

애플실리콘 기반의 맥북이 등장하면서 세상이 참 행복해졌습니다. 베터리도 오래가고 이륙하지도 않고... 이렇게 쾌적한 맥 운영체제는 간만에 느껴보는 즐거움이었습니다. 하지만 의외의 장소

ondemand.tistory.com

 

 

PIP를 통한 mysqlclient 라이브러리 설치 에러 (mysql_config not found)

새로운 개발 장비가 생기면 이전에 사용하던 장비의 환경과 동일하게 준비하는 것이 은근 번거롭습니다. 한동안 손대지 않고 있던 파이썬 Python 장고 Django 프레임웍으로 개발된 코드를 새 장비

ondemand.tistory.com

 

728x90
728x90

웹 사이트를 개발하고 꼼꼼한 테스트를 통해 런칭을 하고나면 왠지 한숨이 놓입니다. 사용자들이 서비스에 대해 좋은 반응을 보이고 열심히 지속적으로 찾아준다면 그 감격은 두배가 되곤 하지요. 하지만 시간이 흐르면서 웹 사이트에서는 새로운 기능들과 메뉴가 추가되고 예상치 못한 사용자들의 활동으로 인해 전에 없던 버그가 도출되기도 합니다. 빠르게 변화하는 시장 상황과 사용자 요구사항에 맞추어 소스코드 변경 및 형상 반영이 바쁘게 돌아가기 시작하면 지엽적인 단위 테스트만 수행한 채 상용 서버로 배포되는 일도 종종 발생하곤 합니다.


단위 테스트처럼 서비스와 기능을 구성하는 가장 기본적인 체크는 당연히 변경된 부분들에 대해 수행해야 합니다. 하지만 웹 사이트, 웹 서비스라면 전체적인 사이트의 동작을 사용자 관점에서 점검하고 관리할 필요가 있습니다. 단순히 호출과 응답을 확인하는 수준에서는 사용자 관점의 테스트가 쉽지 않기 때문에 많은 테스터 분들이 테스트 시나리오에 근간하여 반복적이고 기계적인 테스트 작업을 수행합니다. 하지만 고스트 인스펙터(Ghost Inspector)와 같은 툴을 이용한다면 소규모의 인력으로도 효과적인 테스트를 지속적으로 수행할 수 있습니다.





고스트 인스펙터는 크롬 확장 기능을 통해 제공되는 레코더(Recorder)를 이용하여 사용자가 크롬 브라우저를 이용하여 웹 사이트에 대해 행하는 행동을 꼼꼼하게 기록하여 입력의 자동화와 결과물의 비교는 물론이고 클라우드 기반의 시뮬레이션 환경을 통해 이같은 테스트를 지속적이고 반복적으로 수행하고 결과를 관리할 수 있는 서비스를 제공합니다. 레코더를 이용하지 않더라도 잘 준비된 테스트 설정 도구를 이용하여 스텝 바이 스텝으로 사용자의 동작을 시뮬레이션하고 테스트를 하는 것도 물론 가능합니다.





고스트 인스펙터는 무료 티어를 제공하고 있기 때문에 개인 개발자들도 큰 비용 없이 한달에 100 회의 테스트를 수행해 볼 수 있습니다. 웹 사이트의 동작 상황을 영상으로 촬영하여 보여주는 것은 물론이고 스크린 샷 비교를 통한 웹 사이트 렌더링 이미지 비교 및 API 호출 등 고급 기능들도 100 회의 범주 안에서 제공되고 있기 떄문에 본격적으로 유료 사용을 시작하기 전에 충분히 기능을 테스트하고 서비스 및 테스트 환경에 적합한지 검토해 볼 수 있는 점은 프리미움(Freemium) 서비스만의 장점이라 하겠습니다.






점점 복잡해지는 서비스 환경에서 반복적이면서도 모든 시나리오를 커버하는 자동화 테스트 툴에 대한 니즈가 점점 높아지고 있습니다. 고스트 인스펙터는 현실에서 요구되는 모든 기능들을 완벽하게 제공하지는 못합니다. 하지만 상당한 테스트 영역을 자동화로 커버해 줄 수 있기 때문에 현실에서 사람이 해야 하는 많은 테스트 공수를 줄여줄 수 있다는 점에서 그 의미가 있다 하겠습니다. 10명 정도의 팀원이 한달동안 3만회의 테스트를 하는 비즈니스 상품도 99달러선이니 가격도 나름 합리적인 수준 아닐까요? 반복적인 리그레션 테스트에서 이제 해방을 꿈꿔보시기 바랍니다!




고스트 인스펙터 서비스에 대해 자세히 살펴보기 [바로가기]



728x90

+ Recent posts