feat: #90 feasibility 과목별 데이터(subject_results) 추가

[wngjs8114]

관련 이슈

Closes #90

작업 내용

FE2가 실현가능성 화면에 과목별 카드를 추가하려는데 필요한 데이터가 View에 없어서 추가했다.

feasibility() context에 subject_results 리스트 추가:

• exam_id / subject_name / exam_date / task_count
• required_min_minutes / required_recommended_minutes (과목별 합계)

주요 원칙

과목별 possible/risky/impossible 판정은 포함하지 않았다. AvailableTime이 과목별이 아니라 시험기간 전체가 공유하는 가용시간이라, 과목마다 전체 가용시간으로 판정하면 실제와 다른 결과가 나올 수 있다. FE2가 과목별 상태 배지까지 필요하면 판정 기준을 별도로 정하는 논의가 먼저 필요하다.

테스트

python manage.py test planner → 151개 통과 (dev 기준, #88 미머지 상태라 161개 중 10개 제외)

[6ye0m]

코드 직접 받아서 실제 데이터로 검증했습니다.

계산 로직 정확성

데이터통신: task_count=2 (미확정 작업 정확히 제외), min=50, max=90
운영체제: task_count=0 (작업 없음), min=0, max=0

미확정(is_confirmed=False) 작업이 정확히 제외되고(_confirmed_tasks() 재사용이라 기존 판정 로직과 일관됨), exam_date 순 정렬도 정상입니다. exam_period.exams.all()로 한 번만 쿼리하고 이미 메모리에 있는 tasks 리스트를 파이썬에서 필터링하는 구조라 N+1도 없습니다.

추가로 두 가지 더 확인했습니다.

다른 사용자로 접근 시도 시 404 정확히 확인했습니다 (기존 _get_owned_exam_period() 그대로 유지).
estimated_min/max_minutes가 0인 상태로 확정될 수 있는지 확인해봤는데, AI 분석 확정 경로(study_task_confirm)와 수동 추가 경로(study_task_create) 둘 다 확정 전에 estimate_task_minutes()를 거치는 걸 코드로 확인했습니다. subject_results가 0으로 왜곡될 걱정은 없어 보입니다.

과목별 possible/risky 판정을 넣지 않은 설계 판단도 타당합니다 - 여러 과목이 같은 가용시간 풀을 공유하는 구조에서 과목마다 전체 가용시간 대비로 판정하면 왜곡된 결과가 나올 수 있어서, 이 부분은 별도 논의가 필요하다는 판단에 동의합니다.

검증 결과

python manage.py test planner → Ran 161 tests, OK
python manage.py test → Ran 234 tests, OK
manage.py makemigrations --check → 이상 없음

다만 이번 PR에 테스트가 하나도 추가되지 않았습니다.

bash
git diff origin/dev -- planner/tests.py

결과 없음

161개가 통과한다는 건 기존 테스트가 안 깨졌다는 것만 보여줄 뿐, 새로 추가된 _build_subject_results()가 정확히 동작하는지는 검증하지 못합니다. 이 프로젝트가 새 기능마다 전용 테스트를 붙여온 흐름을 생각하면 이 부분만 보완되면 좋겠습니다.

제안하는 테스트 케이스

확정된 작업만 과목별로 집계되는지 (미확정 제외)
작업이 0개인 과목도 정상적으로 0으로 나오는지
exam_date 순으로 정렬되는지
다른 사용자의 시험기간 접근 시 기존 소유권 체크가 그대로 적용되는지

테스트만 추가되면 바로 승인 가능할 것 같습니다.

[borissal1207]

subject_results 로직 직접 셸에서 실행해서 확인했습니다.

6개 키(exam_id/subject_name/exam_date/task_count/required_min_minutes/required_recommended_minutes) 다 정확히 나오고, 시험일 순 정렬도 잘 됩니다. status/possible 같은 과목별 판정 값도 안 들어있는 것 확인했습니다 — 설명하신 원칙대로 잘 지켜졌어요.

머지 전에 두 가지만 확인 부탁드려요.

1. _build_subject_results에 대한 테스트가 없어서, 추가해주시면 좋을 것 같습니다.

2. 직접 재현해봤는데, "작업 2개를 만들어놨지만 둘 다 미확정인 과목"과 "작업이 아예 없는 과목"이 완전히 동일한 결과로 나옵니다.

FE2 카드에서 "확정 전" 상태와 "진짜 작업 0개" 상태를 구분해서 보여줘야 하나요? 구분이 필요하면 별도 필드(예: has_unconfirmed_tasks)가 있으면 좋을 것 같고, 이번 스코프에서 구분 안 해도 된다면 그냥 넘어가도 될 것 같습니다.

추가로 이 브랜치가 #88(복구안 View 연결) 머지 전 지점에서 갈라져 있어요. #88이 지금 dev에 머지됐으니, dev 최신화하고 테스트 다시 돌려서 정확한 통과 개수로 설명 업데이트 부탁드립니다. (dry-run 해보니 코드 충돌은 없었습니다.)

[wngjs8114]

확인 감사합니다!
_build_subject_results() 테스트는 말씀해주신 케이스 기준으로 추가했습니다. 최신 dev도 반영한 뒤 전체 테스트 다시 돌려서 PR 설명의 테스트 결과도 업데이트했습니다.

미확정 작업만 있는 과목과 작업이 아예 없는 과목 구분은 이번 #90에서는 별도 필드를 추가하지 않는 방향으로 가겠습니다.
현재 feasibility()에서 _validate_task_readiness()가 미확정 작업이나 준비되지 않은 과목을 별도로 검사해서 readiness_error로 전체 계획 생성을 막고 있고, subject_results는 확정된 작업 기준으로 과목별 작업 수/필요시간/시험일만 보여주는 용도로 두려고 합니다.
나중에 과목 카드 자체에서 "확정 전" 같은 상태 표시가 필요해지면 그때 별도 필드와 UI 기준을 같이 정하는 게 좋을 것 같습니다.

[borissal1207]

확인했습니다.

FeasibilitySubjectResultsTests 4개 케이스가 지난 리뷰에서 요청한 항목(확정 작업만 집계 / 작업 0개 과목 / exam_date 정렬 / 타 사용자 404)과 정확히 1:1 대응됩니다. diff도 planner/tests.py에만 113줄 추가로 스코프가 깔끔합니다.
로컬에서 직접 돌려봤습니다: python manage.py test planner → 165 tests, OK, python manage.py test → 238 tests, OK. makemigrations --check --dry-run도 변경사항 없음 확인했습니다.
dev 최신화

git merge-base --is-ancestor origin/dev HEAD 로 확인하니 dev가 완전히 병합돼 있고, 충돌 마커도 없습니다. 말씀하신 dry-run 결과(코드 충돌 없음)와 일치합니다.
has_unconfirmed_tasks 필드 보류 판단

_validate_task_readiness()가 미확정 작업이 하나라도 있으면 readiness_error로 전체를 막는 구조라, 현재 스코프에서 subject_results가 굳이 과목별로 그 상태를 다시 구분할 필요는 없어 보입니다. 다만 이 readiness 체크는 시험기간 전체 단위지 과목 단위가 아니라서 — 나중에 과목 카드에 "확정 전" 배지를 붙이게 되면 그때는 정말 과목별 필드가 새로 필요해질 겁니다. 지금 스코프에선 동의합니다.
이제 approve 하겠습니다. 👍