Call this morning to discuss more nostr testing stuff and I'm thinking of changing the entire project structure.
1) "unit testing" would move to individual client repos.
Use selenium/appium to do all the different kind creation for that client there, publish to in memory relay, verify with sandwich (nprofile…z7r2)'s library, publish to another relay if successful, output events. The benefit of this is that testing config would live along side of the app and client devs would be motivated to update the testing/config if they break it because they have automated testing on their releases.
2) integration testing remains a separate thing, but when it runs it would either import those workflows as templates or run them separately on Arjen (nprofile…7u3d)'s cicd DVM and then the output would be used for the interoperability piece.
What this looks like is basically that there would be code called within client A(b, c, etc)'s test to create an event but also code in a separate repo to verify it renders properly on other clients, create a reply, etc. And developers would be able to run their test suites against other clients they maybe partner with this. Maybe triad could form of a web client, an android client and an iOS client that all run their tests against each other monthly to verify they didn't fuck each others stuff up.
I think the incentives of this are better BC developers get something out of it for their own application and not simply just for helping nostr as a protocol.
au9913
npub16u…6lra7
2025-05-13 15:14:47
Author Public Key
npub16ux4qzg4qjue95vr3q327fzata4n594c9kgh4jmeyn80v8k54nhqg6lra7Published at
2025-05-13 15:14:47Event JSON
{
"id": "e120ef42abedd17361657c752e8129acc7f321241ba08c2a679b643f58773033",
"pubkey": "d70d50091504b992d1838822af245d5f6b3a16b82d917acb7924cef61ed4acee",
"created_at": 1747149287,
"kind": 1,
"tags": [
[
"p",
"e771af0b05c8e95fcdf6feb3500544d2fb1ccd384788e9f490bb3ee28e8ed66f",
"",
"mention"
],
[
"p",
"bbb5dda0e15567979f0543407bdc2033d6f0bbb30f72512a981cfdb2f09e2747",
"",
"mention"
]
],
"content": "Call this morning to discuss more nostr testing stuff and I'm thinking of changing the entire project structure.\n\n1) \"unit testing\" would move to individual client repos.\n\nUse selenium/appium to do all the different kind creation for that client there, publish to in memory relay, verify with nostr:nprofile1qqswwud0pvzu362lehm0av6sq4zd97cue5uy0z8f7jgtk0hz368dvmcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz9mhwden5te0wfjkccte9ehx7um5wghxyctwvshsz8thwden5te0dehhxarj95crztnev94kj6r0dehx2tnrdakj7qzz7r2's library, publish to another relay if successful, output events. The benefit of this is that testing config would live along side of the app and client devs would be motivated to update the testing/config if they break it because they have automated testing on their releases.\n\n2) integration testing remains a separate thing, but when it runs it would either import those workflows as templates or run them separately on nostr:nprofile1qqsthdwa5rs42euhnuz5xsrmmssr84hshwes7uj392vpeldj7z0zw3cppemhxue69uhkummn9ekx7mp0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qg3waehxw309ahx7um5wgh8w6twv5hsef7u3d's cicd DVM and then the output would be used for the interoperability piece.\n\nWhat this looks like is basically that there would be code called within client A(b, c, etc)'s test to create an event but also code in a separate repo to verify it renders properly on other clients, create a reply, etc. And developers would be able to run their test suites against other clients they maybe partner with this. Maybe triad could form of a web client, an android client and an iOS client that all run their tests against each other monthly to verify they didn't fuck each others stuff up. \n\nI think the incentives of this are better BC developers get something out of it for their own application and not simply just for helping nostr as a protocol. ",
"sig": "9cf3eb45bbb23636c2669e0f45060947d9d1cb1feed368d613b7d3598d448f74488afd2f4d60f5633f10bf51d7f1d5f7685ae296af3bb92153a02aca6dcf9b60"
}