go-pkgz / auth / 32636410209
86%
master: 87%

LAST BUILD BRANCH: refs/tags/v2.3.0
DEFAULT BRANCH: master
Ran
Jobs 1
Files 25
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 86.097% (+0.05%) from 86.05%
32636410209

Pull #317

github

paskal 
Assert what the avatar path promises rather than encoded byte counts

Seven tests pinned the exact encoded size of a PNG the standard library
produces, and Go 1.27 changed the encoder, so all seven fail on a clean
checkout with nothing in the repository touched: 569 becomes 507, 999
becomes 1633, 992 becomes 1617, and 960 becomes 1564 in four places.

They assert what the code actually owes its caller now. The generator
emits a 300x300 identicon and the proxy resizes to its configured limit,
and neither moves with a Go release, so the geometry is the durable
claim and the byte count never was.

Three smaller things in the same tests, all of which let a real
regression through:

- exact dimensions rather than an upper bound, since LessOrEqual passes
  a 60x60 result where the resize limit is 120
- the Positive and NotEmpty assertions that sit after a successful
  image.Decode, which cannot fail if the decode succeeded
- nothing in either module inspected a pixel, so a resize that lost its
  Scale call still encodes a correctly sized, entirely transparent PNG
  and the suite stays green. TestAvatar_resize now asserts the result is
  not uniform, which is the only assertion that would notice

CI cannot see any of this: both workflows pin go-version 1.26. Verified
on 1.27 natively and in golang:1.27-alpine, where every package in both
modules passes, and each old assertion fails when restored.
Pull Request #317: Assert what the avatar path promises rather than encoded byte counts

3214 of 3733 relevant lines covered (86.1%)

9.58 hits per line

Jobs
ID Job ID Ran Files Coverage
1 32636410209.1 25
86.1
 GitHub Action Run
Source Files on build 32636410209