Discussion: E2E 테스트 및 버그 리포트 자동화

[cometkim]

어제 얘기 나눴던 테스팅 건을 Jest 가지고 간단하게 PoC 해봤습니다.

jest-puppeteer 환경 구성하고 페이지 로드 직후에 빌드된 유저스크립트를 inject 해주니 아주 잘 동작합니다.

이대로 진행한다면 다음과 같은 레이아웃으로 만들 수 있을 것 같습니다.

const urls = [
   // ...test urls
]

for (const url of urls) {
  await page.goto(url)
  await page.addScript({ ... })

  expect(page).toBeJustNews()
  // * 타이틀, 작성일, 기자, 내용 등등 값 검증
  // * 팝업 열려있는지 검증
  // * 광고 없는지... 어떻게 검증하지
}

그리고 Jest 리포트를 파싱하거나 적절한 리포터를 만들어서 이슈 템플릿 입혀 이슈등록 시키면 될 것 같네요.

예상되는 워크플로우는: 일일 스케줄 -> 뉴스 크롤링/샘플링 -> E2E 테스트 실행 -> (실패 케이스가 있으면) 깃헙 이슈 등록 -> 사이트별 상태(성공, 실패, 미구현) 이미지 업데이트

배제한 것들

어제 얘기나눈 접근 방식이 크게 두개였는데요.

1. 실제로 TM 익스텐션을 로드해서 "완전히 동일한 E2E 환경"에서 테스트
2. JSDom 등 가상 환경에서 파서 동작을 테스트 (...맞나요?)

일단 1번은 Puppeteer 제약사항으로 헤드리스 모드에서는 동작하지 않는데다가 TM을 따로 로드해줘야 하는 번거로움까지 있습니다. 생각해보니 어찌됐건 유저스크립트만 실행하면 되니 불필요한 작업이더군요.

2번은 아무리 생각해도 유닛테스팅 성격이 강한 것 같습니다. 아직 구현되지 않는 파서를 구현할 때 도움을 줄 수는 있을 텐데 "실제로 잘 렌더링 되는지"는 검증이 안되기 때문에 배제했습니다.

여담

TM이 별도 태스크처럼 동작하는 것 같던데, 이게 우선순위가 낮아서 그런지 불러올거 다 불러온다음 just-news 가 실행되는 것으로 보이더라고요.

근데 테스트에선 스크립트를 직접 삽입하니까 엄청 빨리 도는 듯... 다른 최적화보다도 #200 만 해도 사용성 엄청 좋아질 것 같습니다.

[cometkim]

워크플로우는 크게 두가지 중에 선택할 수 있을 것 같아요.

1. 무작위 선택: 본문에 적은대로 크롤링 잡을 만들어서 매번 다른 뉴스를 무작위 선택해서 검증하는 방식
2. 점진적 선택: 커버리지 높은 케이스를 미리 지정해두고, 사용자로부터 보고된 추가 케이스가 있을 때마다 추가하는 방식

[cometkim]

@disjukr 방향성 생각하신거랑 대략 맞는지 피드백 부탁드려요. 괜찮다고 하시면 PR 올리겠습니다. (+ 혹시 CircleCI 로 툴링 바꾸실 의향 있으시면 CI 워크플로우까지 기여 가능할 것 같습니다.)

[disjukr]

저두 어제 대충 요런걸 만들고 있었어용: https://github.com/disjukr/just-news/blob/master/src/test/health-check/index.ts

뉴스기사마다 들어있는 내용이 달라서 (필드에 따라 애초에 기사에 해당 정보가 없을 수도 있고, 기사에 내용이 있는데 누락됐을 수도 있고) check 필드에 파싱된 article 객체에서 어떤 내용을 검사하고 싶은지 정보를 넣으려고 하구용. 일단은 check할 것중에 falsy value가 있으면 에러로 보면 될 것 같아요.

케이스마다 관련된 이슈번호를 넣어놓을 건데, 나중에 이걸 활용해서 옛날 이슈를 다시 열어준다던가, 아니면 새 이슈를 만들고 관련 이슈를 언급한다던가 하는 처리를 할 수 있을 것 같아요.

이런 정보들을 좀 활용하려면 테스트 케이스는 크롤링 하는 것보다는 사람이 넣는게 나을 것 같습니당.

---

e2e는 관심이 없어요. 말씀하신대로 삽을 좀 떠야하거니와, 유저스크립트와 관련된 부분은 잘 바뀌거나 깨지는 부분이 아니라 사람이 확인해도 충분할 거 같아요.

jsdom은 당장은 생각이 없고 나중에 다른 이유로 도입할 수도 있을 거 같긴 해요 (테스트 성능 문제를 해결하기 위해서라거나 ㄹㄹ)

circle ci보다는 github actions 먼저 검토해보고 싶어용

[disjukr]

그리고 브라우저 프로세스에 올릴 테스트 스크립트는 따로 빌드해야할 것 같아용.

[cometkim]

GitHub Actions 관련:

• 다좋은데 레이스가 좀 심한 것 같아요. https://github.com/cometkim/cleankeeper 이런거 만들어 쓰고 있는데 도는 중에 이벤트 새로 들어왔다고 이전에 돌던거 강제종료 시켜버림.

• 어차피 Node 프로세스면 probot 활용하면 뚝딱 만들 수 있습니다. 편해요!

[disjukr]

일단 json 리포트 뽑는 것까지는 만들었네용.

그리고 노가다 거리가 생겼습니다 하핳
https://github.com/disjukr/just-news/blob/master/src/test/health-check/index.ts#L21

이제 해야할게

• 각 뉴스사이트마다 테스트 케이스 최소한 하나이상 넣을 것
• 테스트 리포트를 이쁘게(이미지 파일이라던가?) 만들 것
  • 보여줘야할 것들
    • 파싱이 안 된 경우(article: null)
      • 파싱 중 런타임 에러가 발생한 경우
    • 이상하게 파싱된 경우(problems)
      • 누락됨 ('missing')
      • 잘못됨 ('invalid')
    • 처리시간(duration) 시각화 (5000ms 보다 오래걸리면 색깔이 변한다던가)
• 테스트 리포트를 잘 보이는 곳에(ex: README.md) 보여줄 것
• 주기적으로 테스트 돌릴 것

정도겠네요..

도와주세용=3=3

[cometkim]

https://github.com/vadimdemedes/ink 이거 써보고 싶었는데 여기 써봐도 되용?

[disjukr]

@cometkim 넹 근데 cli에 보여주는 내용이랑 별개로 이미지 리포트도 따로 만들어야할 것 같아용

[cometkim]

테스트 리포트를 잘 보이는 곳에(ex: README.md) 보여줄 것

매번 README update commit 을 넣을수는 없으니 파이프라인에서 "badge 이미지 생성" -> "s3에 업로드" -> "cdn invalidate" 이런식으로 가야겠네요. badge는 3종:

• 성공:
• 실패(오류 있음):
• 테스트 없음/미구현:

마크다운 리포트로 만들어서 README에 미리 넣어둔다고 치면 대략:

예시)

사이트 지원 현황

사이트	지원 정보	상태
ITWORLD	title, timestamp.created, reporters.email
JTBC

[cometkim]

"이미지 리포트"에서 기대하시는 내용들은 어떤것들인가요? 에러 케이스에서 실제 보이는 화면 등인가요?

[disjukr]

이미지로 넣으려는 이유는 말씀하신대로 매번 ci가 남기는 커밋이 안생겼으면 싶어서 그런게 맞아요.

저기 사이트 지원 현황이라고 보여주는 테이블 같은걸 전체를 그냥 이미지로 보여주려고 하는 거구용.
근데 지원 정보 컬럼은 같은 사이트 안에서도 기사마다 다를 수 있어서 넣고싶지 않네요 ㄹㄹ

보여주고 싶은건 전체 사이트중 지금 몇%가 완벽하게 작동하는지,
각 사이트에 대해서 테스트 몇 개 있고 몇 개 통과하는지,

각 테스트마다

• 5초 이상 소요된 경우 걸린 시간 (duration: 5432)
• 테스트 실패한 경우 (type: 'error') => (해석: 테스트 코드를 잘못짠 것. 테스트 코드를 고쳐야 함)
• 테스트 안 실패한 경우 (type: 'ok') => (해석: 정상작동 혹은 구현체(impl)의 잘못)
  • 파싱 실패한 경우 (article: null) => (해석: 파싱 코드 실행중 에러남)
  • 파싱 성공한 경우 (article: { ... })
    • 제목 누락됨 (problems: [['title', 'missing']])
    • 잘못된 작성일 (problems: [['timestamp.created', 'invalid']])

이런걸 보여주고 싶고용,
이걸 위의 테이블처럼 그려보자면

지원 상태

사이트	상태
경향신문	❌ (url, 경향비즈 #58) 5.2초 소요, 제목 누락됨, 잘못된 작성일 ❌ (url) 본문 누락됨
국민일보	❌ (url, 국민일보 일부 페이지 작동하지 않음 #77, Parse image slideshow #44) 잘못된 마지막 수정일, 작성자 이름 누락됨 ✅ (url)
나우뉴스	(테스트 없음)
네이버뉴스	❓ (url)테스트 실패 ❌ (url)23.4초 소요, 파싱 실패

요런 느낌으로 만들고 싶고용

위 처럼 그리려면 그리고 ['reporters.1.name', 'missing'] 등의 값을 => 두번째 작성자 이름 누락됨 같이 바꿔주는 함수도 있어야겟죵. 저거 문자열로 어떻게 매핑하고 싶은지는 나중에 정리할게용

[disjukr]

이미지면 근데 링크 클릭을 할 수 없네 엉엉

[yous]

[![image](image url)](link url) 같은 식으로 감싸면 이미지 링크로 만들 수 있지 않나요? Travis CI 배지처럼요. 아니면 다른 걸 말씀하시는 건가요?

[disjukr]

@yous 리포트 전체를 통이미지로 만들었을 경우를 생각했어요. 테스트 케이스마다 이미지를 따로 만들면 되긴 할텐데 README.md에 리포트가 들어있다면 README.md를 업데이트 하는 커밋이 많이 생길 것 같아서요.

[cometkim]

크훔.... 원하시는 모양새는 이제 이해됐는데 좀 애매하긴 하네요.

당장 생각나는 건 두 방안을 적절히 섞어서 GitHub Issue Tag 를 사용하는 건데요.

• 깨진 테스트 케이스는 이슈로 등록
• 사이트별 Issue Count 뱃지를 생성하고 Tag: "Test Status: Failed" + Status: Opened 필터 링크

해서 README에서는 전체적인 Status를 한눈에 보게 하고, 뱃지를 누르면 각 사이트별 남은 이슈 목록, 다시 이슈로 들어가면 더 상세한 리포트를 볼 수 있게 구성하는 거죠

@disjukr 어떤가요?

[disjukr]

@cometkim 좋은 것 같아요.

소요시간은 근데 이슈로 등록하기엔 애매할 것 같고(예를 들어 그냥 서버가 너무 느려서 5초를 넘기는 경우 해결하기 애매), 이건 README에 평균 소요시간을 이미지로 보여주면 좋을 것 같아요.

그리고 뱃지는 opened issue 숫자를 보여주기보다, 테스트 갯수만큼 네모를 보여주고, 실패랑 성공을 색깔로 구분해서 보여주면 좋을 것 같아요.

ex)

사이트	소요시간	상태
경향신문	⌛5.3s
국민일보	⌛23.4s

---

그런데 봇이 이미 있는 이슈를 또 만들지 않도록 하려면 어떻게 처리할 수 있을까요?

[cometkim]

가닥이 좀 잡혔네요.

그런데 봇이 이미 있는 이슈를 또 만들지 않도록 하려면 어떻게 처리할 수 있을까요?

요건 단순하게 GitHub API 통해서 위에서 언급한 필터로 이슈 긁어서 하나라도 있으면 댓을 달도록 대체하면 될 것 같아요.

[disjukr]

@cometkim 음.. 이미 단 댓글을 또 달지 않으려면...