Yes. I'm not a dev, so I'm reaching, maybe, but is it not reasonable to build test suites for the most commonly used libraries?
Discussion
nostr:npub16ux4qzg4qjue95vr3q327fzata4n594c9kgh4jmeyn80v8k54nhqg6lra7 is working on a nostrCI proof of concept. More details to follow
Not impossible, fairly simple POC. Once the poc is done it's at matter of getting funding to grind out use cases. The matrix of use cases is also fairly trivial to generate.
Likely the hardest part will be the mobile testing.
Probably the idea would be to run these on nostr:nprofile1qqsthdwa5rs42euhnuz5xsrmmssr84hshwes7uj392vpeldj7z0zw3cppemhxue69uhkummn9ekx7mp0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qg3waehxw309ahx7um5wgh8w6twv5hsef7u3d's cicd DVM so anyone can trigger and pay the invoice.
We can use nostr:nprofile1qqswwud0pvzu362lehm0av6sq4zd97cue5uy0z8f7jgtk0hz368dvmcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszxmhwden5te0wa5x2ct59e5xzurs096xzan9wfhzucm09uqsuamnwvaz7tmwdaejumr0dshsdms043 's validation tool, running them on decentralized (GitHub actions) workflow runners using gitworkshop.
These are up to date, with some known inaccuracies (and in production use)
Schema: https://github.com/sandwichfarm/nostr-watch/tree/next/libraries/schemata
TS/JS Validators: https://github.com/sandwichfarm/nostr-watch/tree/next/libraries/schemata-js-ajv
I'm confused what I'm looking at. This isn't something for testing, it's for validating data as it comes into the relay, correct
It's for validating data, in general. A huge percentage of interoperability issues between clients relates to missing tags or missing data within tags.
Validation and QA are different things tho right? Or am I thinking about this incorrectly
Not sure, I was just primarily responding to nostr:nprofile1qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qgwwaehxw309ahx7uewd3hkctcprpmhxue69uhhyetvv9ujuen0w4h8gctfdchxvmf0qyghwumn8ghj7mn0wd68ytnhd9hx2tcpzamhxue69uhhyetvv9ujuurjd9kkzmpwdejhgtcprpmhxue69uhkzapwdehhxarjwahhy6mn9e3k7mf0qyvhwumn8ghj7er9wfnkjemf9ehx7um5wgcjucm0d5hszythwden5te0xy6rqtnxxaazu6t09uq3wamnwvaz7tmzd96xxmmfdejhytnnda3kjctv9uq3wamnwvaz7tmzw33ju6mvv4hxgct6w5hxxmmd9uq36amnwvaz7tmgdyhx67tkda5kxet0w4e8xar0wfujummjvuhszgrhwden5te0vf5hgcm0d9hx6ctcd9kkzmrfwd68xtn0dekxjmn99uq3qamnwvaz7tm99ehx7uewd3hkctcpr9mhxue69uhkwun0w4c8xtnxd9shg6npvchxxmmd9uq3jamnwvaz7tmvd9nksarwd9hxwun9d3shjtnrdakj7qgmwaehxw309ankcetpwdhkuct5daezuer9wchhyetvv9uszrmhwden5te0gphx7uewd3hkctcpr9mhxue69uhks6ewwp6hyurvv4ex2mrp0yhxxmmd9uq3wamnwvaz7tmpw3kxzuewdehhxarj9ekxzmny9uq3vamnwvaz7tmgd9ehgtnwdaehgu3wd3skuep0qqsthdwa5rs42euhnuz5xsrmmssr84hshwes7uj392vpeldj7z0zw3ctsk94x since he linked to the nostrability repo that hasn't been updated in almost 6 months. Wanted to clarify.
If Client A puiblishes a NIP-22 events without a root event tag, then Client B (and perhaps event Client A) won't be able to find it. Schemas can catch this error either in production or in a CI/CD pipeline. It can also detect these issues by fuzz testing events.
I would personally consider that QA, but maybe not?
nostr:nprofile1qqsthdwa5rs42euhnuz5xsrmmssr84hshwes7uj392vpeldj7z0zw3cppemhxue69uhkummn9ekx7mp0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qg3waehxw309ahx7um5wgh8w6twv5hsef7u3d what are you getting at? I'm unsure how you're saying to use this for qa. Like I get it for apps to use, but I don't understand what you're saying about using this when testing clients.
Validation can be one task in the process of QA. It's not the whole thing but def important
But why? The whole point of QA is to use broken events and see how the clients react. Also, it's to use working events and see how they react. Once the test data is generated you won't really have to validate? Sorry I think I'm missing something