Files
RenewCMS/features/article_body_unlimited.qa.md

4.0 KiB

QA: unlimited, optional article body

Part A. HTTP (Go, test/article_body_unlimited_http_test.go)

Setup: in-memory fake article repository plus the real markdown converter as BodyRenderer (so the "json" format of an empty body is genuinely exercised). Build CreateArticle, GetArticle, UpdateArticle use cases and the article handler via NewHandler(...). Mount on a fresh chi.NewRouter() that mirrors api/router.go: POST /v1/article/ and PATCH /v1/article/{id} inside jwtauth.Verifier + Authenticator with a test jwtauth.New("HS256", ...) token. Call validator.InitValidator(). Use httptest. No live server, no real SQLite, no real SMTP.

  1. POST title-only, one request per format (default markdown, html, json): assert 201, body_format, the body value in the JSON response (the Examples table), and that the fake repo has Body "". The json case must produce valid JSON ([]) and not fail encoding.
  2. POST with "body": "" explicitly: same as 1.
  3. POST with strings.Repeat("a", 120000): 201 and the repo body length is 120000.
  4. PATCH with 10001 and 120000 characters: 200 and the stored length matches.
  5. PATCH with "body": "": 200, then GET ?format=json returns body [].
  6. POST title missing, "Ti", and 201 characters: 400, plain text, repo count unchanged.
  7. PATCH guards: bad id gives 400, unknown id gives 404, malformed JSON gives 400.
  8. Update existing tests: in test/edit_article_body_http_test.go remove the case "body over 10000 characters" (line 172) from the 400 table, and any missing-body rejection case (flip it to accepted if present).
  9. Grep that the Integration source no longer contains "max 10000" (see Part C).

Part B. SPA

Automated (Vitest, task test:web). Until the SPA runner exists, report NOT RUN rather than pass.

  • EditorView.spec.ts: delete the "Near the limit" and "Too long" describes (around lines 392 and 405). Add: the neutral count "1,204 words · 7,318 characters" with mocked GET (fixture of 1,204 words / 7,318 characters); "0 words · 0 characters" for an empty article; at 120,000 characters (19,845 words): neutral count, Save and Publish enabled, then Saving ("Saving 120,000 characters. This can take a few seconds."), Saved (count unchanged), and Save failed (PATCH 500, 413 and network error, body kept, Retry resending the same payload).
  • CharacterCounter.vue and web/src/components/tests/CharacterCounter.spec.ts stay (ProfileView and CreateApiKeyModal use them).
  • NewArticleModal spec: Default (empty), Validation ("Ti"), Submitting, 201 handoff, Title rejected (400), Server error (500 and network). Assert the POST payload is exactly {"title": "..."} and that no First paragraph field exists.
  • Static check: grep web/src for BODY_MAX_LENGTH, and for CharacterCounter imports in EditorView and NewArticleModal, returns nothing.

Visual (task visual:check -- editor, task visual:check -- new-article). Hard gate: every capture within 10 %, desktop and mobile, light and dark.

  • editor: states Saved, Unsaved changes, Saving, Save failed, and Very long article (6-9). Reuse the board's sample data ("1,204 words · 7,318 characters", "19,845 words · 120,000 characters", "Saving 120,000 characters. This can take a few seconds."). States showing time-dependent content (the "Saved at" time, "Updated Today, 11:02") are skip: clock-sensitive.
  • new-article: Default, Validation, Submitting, Title rejected, Error. Mocks reuse "Choosing tiles for a small bathroom". The user will update the design .md files only; the board .dc.html frames may still draw a body line in Submitting / Title rejected / Error, so a visual diff there is a known follow-up to raise, not a reason to keep the field.
  • Remove the "Near the limit" and "Too long" entries from web/visual/states.ts (around lines 4712 and 4720) if they belong to the editor group.

Manual: keyboard and focus order in the modal (Title focused on open, Esc blocked while submitting); hover and motion; typing responsiveness in a real browser at 120,000 characters.

Part C. Docs consistency

  • The Integration screen reference text shows no "max 10000" (view /integration).