top | item 44288667

(no title)

evrflx | 8 months ago

I like the idea! We use it actually for a financial application we develop for a bank. We use spring test docs with tests to create example api calls with answers, run reference calculations as part of the test and record the outcome and decisions Both become part of the documentation rendered with asciidoc. We added custom annotations to add documentation snippets thorough the code in addition to using drools and recording the ruleset as well. Feedback is great! But it is no generic approach and involved quite some effort for infrastructure and ongoing maintenance. But well worth the effort given the stakes involved.

Perhaps this helps you as feedback. I am curious how your approach will turn out.

discuss

order

dethstrobe|8 months ago

That's great to know. I was thinking about tackling this from the highest level of abstraction first, so the user interface. I plan on supporting Playwright first for MVP, and then expanding in to Cypress, and maybe even unit testing frameworks.

I feel like backend API documentation is kind of handled with things like Swagger.

How do you think your in house solution compares to something like Swagger or Javadoc?

One of my personal fears (which might be a bit unfounded) since Swagger and Javadoc are generated based off of code comments, and not tests, and there is a possibility that they could get out of sync with implementation. But that might be unfounded. When I worked on Java and wrote unit tests and generated Swagger docs, we never actually ran in to the problem of these things becoming out of sync.

I theorize that the front end isn't as well disciplined as it is in the backend world as well. Which is where I think this idea of Test2Doc will really shine.