hitchstory
jsverify
hitchstory | jsverify | |
---|---|---|
23 | 5 | |
84 | 1,666 | |
- | 0.1% | |
9.1 | 1.8 | |
16 days ago | about 3 years ago | |
Python | JavaScript | |
GNU General Public License v3.0 or later | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
hitchstory
- Hitchstory – Type-safe StrictYAML Python integration testing framework
-
Winner of the SF Mistral AI Hackathon: Automated Test Driven Prompting
I built something like this too:
https://github.com/hitchdev/hitchstory/blob/master/examples%...
- Prompt Engineering Testing Framework
-
Non-code contributions are the secret to open source success
I took the same approach to "docs are tests and tests are docs" with integration testing when I created this library: https://github.com/hitchdev/hitchstory
I realized at some point that a test and a how-to guide can and should actually be the same thing - not just for doctests, but for every kind of test.
It's not only 2x quicker to combine writing a test with writing docs, the test part and the docs part reinforce each other:
* Tests are more easily understandable when you attach written context intended for human consumption.
* Docs are better if they come attached to a guarantee that they're valid, not out of date and not missing crucial details.
* TDD is better if how-to docs are created as a side effect.
-
Ask HN: Are there any LLM projects for creating integration tests?
I have created a project for easily writing this type of test with YAML:
https://github.com/hitchdev/hitchstory
I dont think that this type of task is really appropriate for an LLM though. It is better to use hard abstractions for the truly deterministic stuff and for other stuff where you may need to do subtle trade offs (e.g. choosing a selector for the search bar) an LLM will generally do a bad job.
-
Should you add screenshots to documentation?
For those interested in the concept of having permanently up-to-date documentation with screenshots I built this testing framework based upon the idea that good documentation can be a autogenerated artefact of good tests:
https://github.com/hitchdev/hitchstory
-
How to add documentation to your product life cycle
I don't like gherkin. It's it has very awkward syntax, it's not type safe, it's very verbose, it has no ability to abstract scenarios and rather than being a source for generating the documentation it tries to be the documentation.
Nonetheless, there is a small number of projects where they either work around this or it doesn't matter as much. I find that most people that apply gherkin to their projects find it doesn't work - usually for one of the above reasons.
I built https://github.com/hitchdev/hitchstory as an alternative that has straightforward syntax (YAML), very strict type safety (StrictYAML), low verbosity, and is explicitly designed as a source for generating documentation rather than trying to be the documentation.
-
Beyond OpenAPI
I built this because I had the same idea: https://github.com/hitchdev/hitchstory
If the specification can be tested and used to generate docs and can be rewritten based upon program output then the maintenance cost for producing docs like these plunges.
-
Optimizing Postgres's Autovacuum for High-Churn Tables
-c fsync=off -c synchronous_commit=off -c full_page_writes=off
I got the answer from Karen Jex at Djangocon 2023.
I used it to build some integration tests which exhibit best practices: https://github.com/hitchdev/hitchstory/tree/master/examples/...
I considered using tmpfs but I wanted to cache the entire database volume and couldnt figure out how to do that with podman.
-
Elixir Livebook is a secret weapon for documentation
This is incredible work.
To anyone curious, I highly recommend:
- https://hitchdev.com/hitchstory/approach/
- https://hitchdev.com/hitchstory/why-not/
From the overall RDD/BDD type home page:
- https://hitchdev.com/hitchstory/
The entire product site is a thing of richly informative beauty.
---
My only question was whether the generated 'docs' snippets would add value over just reading the story in your DASL. Any markdown site generator (such as the chosen Material for MKDocs) can just embed the ```yaml anyway. But then I realized what was generating e.g. …
- https://hitchdev.com/hitchstory/using/engine/rewrite-story/
… and how superior that is to typical docs, especially typical docstring or swagger factories.
jsverify
-
The 5 principles of Unit Testing
Libraries like JSVerify or Fast-Check offer essential tools to facilitate property-based testing.
-
Ask HN: What's your favorite software testing framework and why?
I tend to use anything that offers property-testing, since tests are much shorter to write and uncover lots more hidden assumptions.
My go-to choices per language are:
- Python: Hypothesis https://hypothesis.readthedocs.io/en/latest (also compatible with PyTest)
- Scala: ScalaCheck https://scalacheck.org (also compatible with ScalaTest)
- Javascript/Typescript: JSVerify https://jsverify.github.io
- Haskell: LazySmallCheck2012 https://github.com/UoYCS-plasma/LazySmallCheck2012/blob/mast...
- When I wrote PHP (over a decade ago) there was no decent property-based test framework, so I cobbled one together https://github.com/Warbo/php-easycheck
All of the above use the same basic setup: tests can make universally-quantified statements (e.g. "for all (x: Int), foo(x) == foo(foo(x))"), then the framework checks that statement for a bunch of different inputs.
Most property-checking frameworks generate data randomly (with more or less sophistication). The Haskell ecosystem is more interesting:
- QuickCheck was one of the first property-testing frameworks, using random genrators.
- SmallCheck came later, which enumerates data instead (e.g. testing a Float might use 0, 1, -1, 2, -2, 0.5, -0.5, etc.). That's cute, but QuickCheck tends to exercise more code paths with each input.
- LazySmallCheck builds up test data on-demand, using Haskell's pervasive laziness. Tests are run with an error as input: if they pass, we're done; if they fail, we're done; if they trigger the error, they're run again with slightly more-defined inputs. For example, if the input is supposed to be a list, we try again with the two forms of list: empty and "cons" (the arguments to cons are both errors, to begin with). This exercises even more code paths for each input.
- LazySmallCheck2012 is a more versatile "update" to LazySmallCheck; in particular, it's able to generate functions.
-
Property Based Testing Framework for Node
The usage of hypothesis is very intuitive and simple, and presents the concept of property-based testing perfectly. So I also wanted to find an equivalent alternative in Node. Two of them have high star ratings on Github, JSVerify with 1.6K stars and fast-check with 2.8K stars. So I took some time to study fast-check a little bit and try to get closer to my daily work.
-
Machine Readable Specifications at Scale
Systems I've used for this include https://agda.readthedocs.io/en/v2.6.0.1/getting-started/what... https://coq.inria.fr https://www.idris-lang.org and https://isabelle.in.tum.de
An easier alternative is to try disproving the statement, by executing it on thousands of examples and seeing if any fail. That gives us less confidence than a full proof, but can still be better than traditional "there exists" tests. This is called property checking or property-based testing. Systems I've used for this include https://hypothesis.works https://hackage.haskell.org/package/QuickCheck https://scalacheck.org and https://jsverify.github.io
-
React to Elm Migration Guide
Using create-react-app, you’ll run npm test which uses Jest internally. If you are dealing with a lot of data on the UI, or using TypeScript, use JSVerify for property tests. For end to end tests, Cypress is a great choice.
What are some alternatives?
bumblebee - Pre-trained Neural Network models in Axon (+ 🤗 Models integration)
greenlight - Clojure integration testing framework
testy - test helpers for more meaningful, readable, and fluent tests
ospec - Noiseless testing framework
LazySmallCheck2012 - Lazy SmallCheck with functional values and existentials!
examples - Tests that rewrite themselves. Tests that rewrite your docs.
fast-check - Property based testing framework for JavaScript (like QuickCheck) written in TypeScript
explorer - Series (one-dimensional) and dataframes (two-dimensional) for fast and elegant data exploration in Elixir
datadriven - Data-Driven Testing for Go
php-easycheck - Mirror of http://chriswarbo.net/git/php-easycheck