Pushing this again because awesome.
nostr:note19lr2ln5ppczfvkqlhnevpqay53s27lucsz5ah5mqd25j2zlju3rqs9246p
Discussion
Okay, let me try to explain this in normal.
1)
NIPs are specifications (descriptions) of what some function should do. Like, there's a NIP for updating a follow list.
But specs are inherently buggy because they are just freely-written text. People try to correct and edit them, but it's sort of futile. One part doesn't match the other, one section conflicts with another, something gets deleted by accident or copy-pasted in incorrectly.
2)
Josua asked me about BDD and I said that we were skipping specs in our project and just writing Gherkin scripts, that we would use manually, initially, and then automate, to test the system.
3)
And he's started doing the same... to the NIP specs.
He's creating tests for the specs that could eventually run dynamically. You could eventually even stop looking at the specs and just pull his latest test-release, to ensure that none of the spec changes break your implementation.
4)
This makes the spec itself into an implementation of the spec.
5)
And you could use it to enforce inheritance, by implementing things using object-oriented design, in the test.
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.
6)
The genius of Gherkin is that he can create the test and an implementation of it, and everyone else can pull the test and have their own implementation of it, that ran on their own system.
Or they could just do the test manually, before every release.
It's a universal test.