What is it for
JNarrate is for writing behaviour specifications (a.k.a. examples/acceptance tests/story tests/etc) in code. Some teams prefer to write their acceptance tests in code rather than in plain text files or html.
Refactoring of acceptance tests when they are written in HTML (like FIT) or plain-text is (like RSpec or JBehave) is often a pain. In the absence of refactoring tools for HTML or plain-text based frameworks some teams prefer to write the tests in code which, thanks to powerful refactoring features in modern IDEs, makes refactoring of tests much easier.
You could argue that my time would have been better spent writing refactoring tools for plain-text or html accetpance-test/BDD frameworks but I have a vision for achieving the best of both worlds - watch this space!
For and against acceptance tests in code
The point of acceptance tests is for the development team and the customer to be able to collaborate on understanding and thus describing the capabilities that should be added or refined by a user story. You could argue that writing the tests in code reduces that collaboration because many customers would be scared off by it.
My goal is to write something that doesn't scare off non-technical customers. Considering my 10 year old son understood the examples I showed him with minimal explanation, I think I'm roughly on the right track.
Some teams ask testers and/or customers to write the tests but I think it's important that it is a collaborative exercise involving programmers, testers and customers. I think the danger with codified acceptance tests is that customers and non-technical testers may not be as involved in the process - which would be bad... but my experience has been that the development team that is keen enough to want to write these tests is keen enough to pro-actively encourage and facilitate collaboration with their customers.
I'm not for or against writing acceptance tests in code although I don't think it's the ideal... similarly, I don't think the current plain-text and html based frameworks are the ideal due to the maintenance difficulties when refactoring statements.
What I recognise is that there are teams out there writing acceptance tests in code, I wanted them to have an API that facilitates readability and maintainability. I hope to progressively add capabilities to the framework so that teams can have the best of both worlds.