nostr:nprofile1qythwumn8ghj7ct5d3shxtnwdaehgu3wd3skuep0qyt8wumn8ghj7etyv4hzumn0wd68ytnvv9hxgtcqypu8xwr40lp96ewdj2fef408wy70gd3carf9n6xu7hrnhq6whpgly925h0z , nostr:nprofile1qy28wue69uhnzv3h9cczuvpwxyargwpk8yhsz3rhwvaz7tmed3c8qarfxaj8s6mrw96kvef5dve8wdrsvve8vvehwamxx7rnwejnw6n0d3axu6t3w93kg7tfwechqutvv5ekc6ty9ehku6t0dchsqgrwg6zz9hahfftnsup23q3mnv5pdz46hpj4l2ktdpfu6rhpthhwjv0us2s2 , nostr:nprofile1qyv8wumn8ghj7urjv4kkjatd9ec8y6tdv9kzumn9wsq3vamnwvaz7tmjv4kxz7fwwpexjmtpdshxuet5qqsqfjg4mth7uwp307nng3z2em3ep2pxnljczzezg8j7dhf58ha7ejgqgzx3h , has anyone applied to build a test suite for nostr?

Is there any reason to think this is an unreasonable task, nostr:nprofile1qyghwumn8ghj7vf5xqhxvdm69e5k7tcpz4mhxue69uhkzet8d9ejuat50phjummwv5hsqgpm7rrrljungc6q0tuh5hj7ue863q73qlheu4vywtzwhx42a7j9n5zgwjy3 , nostr:nprofile1qyw8wumn8ghj7un9d3shjtnzd96xxmmfdecxzunt9e3k7mf0qy2hwumn8ghj7un9d3shjtn4w3ux7tn0dejj7qpqutx00neqgqln72j22kej3ux7803c2k986henvvha4thuwfkper4sau8ykj ?

Reply to this note

Please Login to reply.

Discussion

nostr:npub1zafcms4xya5ap9zr7xxr0jlrtrattwlesytn2s42030lzu0dwlzqpd26k5 had an idea of NostrCI. Not sure if that went anywhere.

I'd bet on him.

Ehhhh, I don't see how a generic test suite would catch the types of issues Derek is pointing out, but perhaps I am regarded . Usually they have to be app specific and extremely well planned out to catch crashy type scenarios

nostr:npub1zafcms4xya5ap9zr7xxr0jlrtrattwlesytn2s42030lzu0dwlzqpd26k5 has wanted something like that for years and I always tell him it's an impossible task.

I think he just means a common test suite

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?

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.

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

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