scribe-org / scribe-org/Scribe-Server

Epic: Add Test suite and coverage for the Scribe-Server v1 API

Open
#76 6 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

testing
Dominant language
Go
Stars
12
Forks
14
Avg merge
1d 4h
Merged PRs (30d)
4

Description

What this is about

Scribe-Server works, but it has no tests. Right now, if someone changes the code and breaks something, nothing tells us. We only find out when the client app(Android or iOS) stops working.

This epic fixes that, one small piece at a time.

The proposed plan

We're at 0% test coverage. We're not going to fix that in one giant PR. Instead, each sub-issue covers one small part of the code. Someone picks one, writes tests for it, and coverage goes up a little.

0% -> 1% -> 3% -> 8% -> and so on, until we're happy with the number.

Slow is fine. The only rule is that it always goes up, never down.

How to help
  1. Pick a sub-issue from the list below and comment that you're taking it.
  2. Write the tests.
  3. Run make test to check they pass.
  4. Check that coverage went up:
go test ./... -coverprofile=coverage.out
go tool cover -func=coverage.out | tail -1

Put the before and after numbers in your PR, like Coverage: 3.4% -> 5.1%.
5. Open a PR, link it to the sub-issue, and ask for review.
6. When it's merged, pick the next one.

If coverage didn't go up, the tests probably aren't reaching new code. Mention it in the PR and we'll look together.

Start here

I'll do the smallest sub-issue first and get it merged, so there's a real example in the repo to copy from. Wait for that one before starting yours if you're unsure what a good test PR looks like here.

New to Go testing? The early sub-issues are marked good first issue — they're plain functions with no database involved. Good place to start.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by waiting for the initial example sub-issue mentioned in the issue, then choose one small API area and run make test. Use go test ./... -coverprofile=coverage.out and go tool cover -func=coverage.out | tail -1 to verify the tests pass and coverage increases; report the before and after coverage numbers when done.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
backend-api-design, testing-qa
Issue type
Refactor
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.