· 톺아보기

개발 자체 서비스 만들다보니..

아저기요 · · 수정

조회 1,682 · 공감 0 · 댓글 13


테스트 코드에 대해 개념을 참 알기 어렵네요


처음에는 tdd로 빡시게 만들었다가 아 ai로 만드는데 이거 너무 병목 현상 심한데..


라고 생각해서 (물론 좋은 경험이긴 했어요)


다음 프로젝트는


그냥 테스트 코드없이 개발을 하고 있긴한데


이게 아직까지는 큰 문제가 없어서..


테스트 코드가.. 이게 


테스트코드 돌린것만으로도 실제 서비스가 동작된다는걸 완벽 검증하게 되는건지


왜냐면 처음에 tdd로 개발할때


테스트코드에서는 그린인데 실사용에서는 red 인경우가.. 종종 있더라구요

제가 잘 못짜서 그렇긴 한것같은데


이게 테스트코드 개념이..


기능 추가할때 기존 기능 안깨지게 하는게 더큰 의미 인지


아니면 테스트 올 그린되면 문제없구나 라는 그 신뢰성의 의미인지..


혹시 여러분은 어떻게 생각하시나요 

댓글 13

  1. Originium ·
    일단 테스트코드는 결국 테스트 관점을 잘 짜셔야 합니다. (뭘 테스트할것인가? 어떤 것이 맞는 동작인가? 어디까지 테스트할 것인가?)
    다 테스트하면 말씀대로 올 그린으로 신뢰성을 가지게 할 수도 있죠. 그러면 좋은데 빡세지니 트레이드 오프가 있는거구요.
    애매하면 핵심로직만이라도 짜시는 걸 추천 드려요.

    리그레션 테스트를 하고 싶으시면 전반적 코드에 대해서 대부분 커버하게 작성 하셔야겠죠.
  2. 아저기요 ·
    @Originium님 아우 실무 경험이 없다보니 직관적인 경험이 없어서 두루뭉실 하네요 사실 혼자 개발해서 그렇지 대형 프로젝트면 테스트 코드 돌렸을때 red 나온걸로 본인의 수명을 연장시키는 정도일텐데 말이죠.. 그런 관점에서 접근해야 겠죠
  3. 할수이따 ·
    tdd도 계층이 있고, atdd수준에서 짜시는게 좋습니다
    더군다나 서비스 개발이면요ㅎ

    tdd가 탄생한 시기를 보면 오히려 si가 성행하던 시기라, tdd는 si쪽에 더 잘맞을거라는게 제 생각입니다
    (참고로 저는 si경험은 없습니다)

    + 아 오해가 있을까봐 서비스 개발 쪽에만 있었습니다
  4. 아저기요 ·
    @할수이따님 근데 잘몰라서 그러는데 서비스 쪽은 목업으로 많이 테스트해서 테스트 환경이랑 실제환경이랑 많이 다르지않아요? 테스트코드의 신뢰도가 좀 떨어지는 편아니에요? 실제로 최근에 목업 테스트에는 통과되서 배포해서 전세계 윈도우 맛탱이가게 만든 프로그램 있엇던걸로 기억해요
  5. 할수이따 ·
    @아저기요님

    Tdd도 분파(?) 같은게 있는데

    Mockist와 클래시스트로 나누어지는데, 이 경계를 잘 타는게 중요해요, 저는 클래시스트 쪽인데 되도록 Mock을 안쓰긴합니다(외부 인프라 쪽만 mock)

    실환경이랑 동일한 테스트 환경을 꾸미는게 제일 좋긴 하죠 ㅎ
  6. 수퍼야옹 ·
    @아저기요님 mock을 사용하는 경우는 네트워크가 끊긴 상태(비행기에서 코딩)이나 느린 경우에 사용해야 합니다. 기타 비용이 많이 든다던지 구현이 안 되었다던지 비결정적 상황이라던지에서도 사용합니다. mock을 사용했으면 당연히 마지막에 통합테스트를 거쳐야 하구요. 좀 더 좋은 대체물(fake, 데이터베이스라면 인메모리 데이터베이스)이 있다면 그걸 사용하는게 mock보다 더 좋습니다.
    실제 환경에서 테스트할 때 느리지 않다면 실제 환경에서 하는게 더 정확하지요.
  7. 조나 ·
    개인적으로 테스트는 한 번 한 삽질은 두번 안 한다의 의미로 접근하고 있습니다.
    예전에 메모리 직접 access 할 때는 A 값을 변경했는데, 가끔 B 값이 바뀔때가 있어서 (메모리 범위 넘어가버리다보니)
    거의 필수적으로 덕지덕지 넣었는데, 요즘은 그냥 오류났을 때마다 하나씩 추가하는 마음가짐으로 가져가고 있습니다.
  8. 아저기요 ·
    @조나님 이렇게 한다는것도 들었어요 일단 개발하고 오류 생기면 그 오류 두번 안뜨게 하는 느낌으로 접근하더라구요
  9. 할수이따 ·
    @조나님

    tdd와 테스트를 작성한다의 개념이 혼용되어있는거 같네요~!
  10. 조나 ·
    @할수이따님 네~ TDD 는 아니긴 합니다. 유닛테스트 개인적인 사용법 정도로 생각해주시면 될 것 같아요. 대부분 프로젝트들이 TDD를 할 수 있을만큼 확정되서 시작되는 경우가 잘 없긴 하더라고요. SI 면 가능할 것 같은데 말이죠.
  11. 할수이따 ·
    @조나님

    아하 그러셨군요~ 주변에서 많이들 이런방식으로 쓰시는거 같아요 ㅎㅎ
  12. 리안 ·
    저는 비즈니스 로직만 테스트 작성합니다.
    ui쪽은 안하고요. ai 는 ui쪽 코드까지 테스트를 짜서 병목이 좀 많더라고요.
    (취향문제지만)
  13. 수퍼야옹 ·
    TDD에서 테스트 코드를 만드는 것은 다른 테스트와는 다르게 게임처럼 빠른 피드백을 사람한테 주어서 자신감을 가지고 코드 작성을 진행할 수 있게 하는게 목표입니다. 모든 잘못된 경우를 막는다는거나 새 기능을 넣었을 때 기존 기능을 안 깨지게 하는게 목표가 아닙니다.
    모든 잘못된 경우를 막는 것은 별도의 테스트 담당자가 필요합니다. 예를 들어 삼각형의 각 점의 위치가 정확한가를 테스트하려면 TDD는 몇 개만 하고 넘어가지만 제대로 하려면 수십개의 테스트를 해야 합니다.

모두의공원 최근 글

모두의공원 목록 더 보기