bleedingdeacons / fellowship / 33947010495
90%

DEFAULT BRANCH: main
Ran
Jobs 1
Files 57
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: 92.137% (+67.5%) from 24.646%
33947010495

push

github

web-flow 
fix: escape the device status cell at each value, and raise coverage to 92% (#6)

* test: cover the four wpdb repositories

Mostly assertions on the WHERE clause, because in two of these the WHERE
clause is the security control and there is nowhere else to check it.

A handset marks a message read by naming it, and the statement carries
the member's own address -- so a request naming somebody else's message
affects nothing and answers exactly as one naming a message that does
not exist. Move that condition into a caller and any handset can mark
any message read.

Revocation works the same way: every lookup that could authenticate a
handset carries revoked_at IS NULL, so a revoked token is
indistinguishable from an invented one at every call site. A refactor
that simplified one of those queries and filtered afterwards would leave
a revoked handset working until somebody noticed. The admin list and
findById deliberately do not filter, and that is asserted too.

A reset token lookup refuses a blank hash before the query runs, because
otherwise it matches every row with no reset pending and the first one
back is somebody's account.

A failed sign-in never creates a credential row: an unknown address has
no password to guess, and seeding one would turn the table into a list
of every address anybody has ever tried.

Needed a local $wpdb double. wp-mocks ships one but it is final and
extends nothing, and these repositories type-hint the real wpdb on
purpose -- something that is not a database connection is a wiring fault
worth failing on. So the bootstrap declares a minimal wpdb and
Support\RecordingWpdb extends it, which is also what makes asserting on
the generated SQL possible at all.

* test: cover the message REST surface

Two properties carry the weight, and neither is visible from outside.

The inbox hands back sealed envelopes and nothing else. Bodies are
stored in plain text and this server can read them -- a documented
decision, and what makes the ... (continued)

3199 of 3472 relevant lines covered (92.14%)

6.06 hits per line

Coverage Regressions

Lines Coverage ∆ File
8
94.69
83.13% fellowship/fellowship/src/Admin/DevicesPage.php
5
90.1
90.1% fellowship/fellowship/src/Admin/ComposePage.php
3
76.32
-7.89% fellowship/fellowship/src/Crypto/MessageSealer.php
1
95.07
95.07% fellowship/fellowship/src/Admin/SettingsPage.php
1
82.35
-2.94% fellowship/fellowship/src/Auth/Providers/AppleProvider.php
1
91.89
56.76% fellowship/fellowship/src/Auth/Providers/FacebookProvider.php
1
87.5
59.38% fellowship/fellowship/src/Auth/Providers/GoogleProvider.php
1
87.5
61.11% fellowship/fellowship/src/Auth/Providers/MicrosoftProvider.php
1
92.5
85.0% fellowship/fellowship/src/Core/Cipher.php
1
89.06
73.44% fellowship/fellowship/src/Core/Settings.php
1
92.0
56.0% fellowship/fellowship/src/Logger/HasLogger.php
1
0.0
-12.5% fellowship/fellowship/src/Messaging/Message.php
1
90.63
-1.56% fellowship/fellowship/src/Messaging/MessageRequest.php
Jobs
ID Job ID Ran Files Coverage
1 33947010495.1 57
92.14
GitHub Action Run
Source Files on build 33947010495