I forgot how tedious it is to chase code coverage when writing tests.
Technical Discussion
2
Posts
2
Posters
0
Views
-
I forgot how tedious it is to chase code coverage when writing tests.
However this was part of the reason that made me include the "boring" parts of building a robust library into the goals set for the #nlnet grant.
So after a couple of days of work I finally got the first of the storage backends for the #GoActivityPub library go past 80% test coverage.
I hope I can reuse some of the test logic in the other backends, as they need to perform identically.
-
I forgot how tedious it is to chase code coverage when writing tests.
However this was part of the reason that made me include the "boring" parts of building a robust library into the goals set for the #nlnet grant.
So after a couple of days of work I finally got the first of the storage backends for the #GoActivityPub library go past 80% test coverage.
I hope I can reuse some of the test logic in the other backends, as they need to perform identically.
@mariusor I agree that finding those last percents of coverage can be a pain.
But yes, more so trying to get a full app coverage up is hard and unsatisfactory work.
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@mariusor I agree that finding those last percents of coverage can be a pain.
But yes, more so trying to get a full app coverage up is hard and unsatisfactory work.
-
I forgot how tedious it is to chase code coverage when writing tests.
However this was part of the reason that made me include the "boring" parts of building a robust library into the goals set for the #nlnet grant.
So after a couple of days of work I finally got the first of the storage backends for the #GoActivityPub library go past 80% test coverage.
I hope I can reuse some of the test logic in the other backends, as they need to perform identically.
-
@silverpill @helge@mymath.rocks @helge@mastodon.social @julian can y'all copy me out — I just CC'd Julian as lead on forums taskforce, I don't personally care that much
-
>"Who can create topics?" with possible values being "Everyone", "Followers", or "Moderators".
I am noticing that each value here is a collection.
For the property name, I'd use the canDo convention that is already used by some Fediverse platforms:
{ "canCreateThread": "<collection-id>" }
-
helge@mymath.rocks yes, you're right. Piefed does, but also WordPress, so there's already some buy-in from implementors.
So I'd recommend that any guidance include this usage as well.
-
I guess piefed has postingRestrictedToMods to restrict posting using a boolean flag.
I have already voiced my dislike for all these boolean flags a few times. Would it be possible to have in addition an informative property value? E.g. "Who can create topics?" with possible values being "Everyone", "Followers", or "Moderators".
This would fit well with the mechanism proposed in FEP-19b3: Specifying Properties of a Service. It would also ensure that the information is visible to most people. Meaning increased interoperability.
-
... but importantly, this also might not mean the forum itself allows remote content creation, so you have to check for a boolean bit in the actor that allows for it... or its omission.
That last part is as yet undefined in an FEP.
helge@mastodon.social silverpill@mitra.social thisismissem@hachyderm.io
-
thisismissem@hachyderm.io thanks for the ping.
helge@mymath.rocks there is a very specific condition... You can only assume a topic was added to a community/category/forum if it was addressed to a group actor on your instance (because you control the content ingestion) or if the group actor itself announces it.
Otherwise it's membership state is only a guess. You can explicitly signal intent to post to a community/category by putting the group actor in audience.
