nostr:npub1axy65mspxl2j5sgweky6uk0h4klmp00vj7rtjxquxure2j6vlf5smh6ukq I don't know if you knew all that, but now you know.
😅 He's going to be like WTF?
Of course, the next logical question would be:
What do we still need specs for?
Couldn't we just say: "Your stuff must pass this test, to be conforming with NIP-02 FollowList."
And then people could check what your implementation covered, by just running the test and seeing what came up green. And you could run it continuously on their build server, and you'd get a notification, when something that had been green turned red.
Do I sound insane again? Sorry.
Let me shut up and code. Later.
Okay, I'll stop, now.
Well, or continue 😄
Feel free to have a look at my little mess here: https://github.com/schmijos/nostr-voliere/tree/main/features
Maybe you‘ve got a better idea on how to structure the specs.
You've named it after bird cages? Is there some significance?
The idea is a falconry but for nostriches. It makes the not flying bird fly I guess. 🤷♂️
Hm… nostrichcote 🤔
I'd add a NIP01, NIP02, etc. folder layer to the support folder, otherwise you're going to end up drowning in feature files.
Like I was saying before (maybe you're already doing this), it would be useful to find similar objects and group them and work with inheritance.
This goes back to the "generic reply note kind" debate, but it probably wouldn't only apply to that. Tags would be an obvious one, for instance.
Or simply the core structure of notes. Each test json should be a full example of a complete event json.
I always feel confused, reading through the specs, to see similar things written slightly differently, or only partly. The test should define the minimum viable version of each, once, and then add stuff to other versions. And then people would always see THE WHOLE JSON, when looking at the test.
Or something like that. I don't know. I suck at object-oriented design, but you probably don't.
This is a good example of how powerful this is.
https://github.com/schmijos/nostr-voliere/blob/main/features/01_filtering.feature
You got good at this, really fast, BTW. I'm used to writing these for website tests, so it's interesting to see them applied a layer down.
The type of insane some wouldn't doubt to hop into the ride with, at least
Point 5) ringed bells on instancing wen building virtual built environments (3d computer graphics): you present to the user the projection (child) of the object (parent) on its needed version. At backstage the builder edits the object matter as necessary and pulls the projection however it's needed, that way you don't duplicate object's matter but its script only...
About point 2), which BDD it'd be of these? 
behavior-driven development
It's an offset of test-driven development that focuses on user acceptance tests. That's why the tests just read like formalized English.
