hitchstory

10 ms·

61.
by hitchstory 2y ago
TDD != starting at unit level. It's about red-green-refactor. Or, it should be anyway. People talk about how it "drives" design but I dont think it should. I think tests should be as design-agnostic as possible, providing fr
62.
by hitchstory 2y ago
This is why on greenfield projects I start with an end to end test and do red-green-refactor with it. This lets me defer many architectural decisions (those decisions are usually of a better quality when done during the refactor step) while
63.
by hitchstory 2y ago
>There are areas at the edges where the mocking/stubbing required to really follow TDD cause make changes harder but never find bugs That's not TDD that's either a badly designed unit test or (more likely) you should have
64.
by hitchstory 2y ago
I wrote a systems/integration testing framework for this purpose specifically and I wrote a few essays alongside it. It has the same name as my handle. Not much traction, unfortunately. Id be interested in any comments you might have.
65.
by hitchstory 2y ago
It's called TDD not UTDD. I frequently do TDD with integration and end to end tests. The type of test should be dictated by the nature of the code, which TDD doesnt have an opinion on. TDD is about following red-green-refactor.
66.
by hitchstory 2y ago
If you do test-after you have to keep a mental tally of new scenarios to test when making code changes. This makes it more unreliable since it's easy to forget one of those scenarios or mix it up with an already tested scenario. TDD le
67.
by hitchstory 2y ago
If it remains perfectly bug free until the end of time then yes it's fine /s
68.
by hitchstory 2y ago
Tests are usually soul crushing and boring for the same reason PHP was in 1999 - a complete lack of structure, tooling and separation of concerns made it tedious and difficult. I find it interesting that when people describe to me how they
69.
by hitchstory 2y ago
This doesnt make a lot of sense. The set of things your software cant do is infinite. The set of potential errors is massive and many if not most are unrelated to domain logic.
70.
by hitchstory 2y ago
That's just one example of it. Other examples: * Replacing automated tests with (quicker) type checking and running it on a git commit hook instead of CI. * Replacing slower tests with faster tests. * Running tests before merging a PR
71.
by hitchstory 2y ago
* investment (instead of dogma) driven approach to testing * hermetic end to end tests - tests that test your code in a hermetically sealed environment using fakes. * automatic generation of documentation from story driven tests
72.
by hitchstory 2y ago
>I’ve been through this documentation story before. I can predict how it ends. By the time you read the documentation it’s out of sync with the code so you end up reading the code anyway. But then you feel bad, so you write more document
73.
by hitchstory 2y ago
I did something similar but with my phone, the android orgzly app, termux, jinja2 and latex. I cribbed a CV template from overleaf and put some jinja2 in it to take the content from CV note in my note taking app: https://hitchde
74.
by hitchstory 2y ago
I used to be really good at working with big balls of mud. I actually even started enjoying it at some point - it felt like a mixture between a crossword puzzle and archaeology. There was also something nice about being good at something ot
75.
by hitchstory 2y ago
The skeleton test-generating-docs example I built to exhibit the framework actually does this. Here's an example: https://github.com/hitchdev/hitchstory/blob/master/examples/... It records a vi
76.
by hitchstory 2y ago
That's very cool. I think screenshotting needs to be integrated into the tests though - if a scenario involves a wizard or something, the latter screenshots will be dependent upon the actions in earlier steps.
77.
by hitchstory 2y ago
It works for user facing documentation too. There are actually pretty good reasons for this - e.g. you can use the test to autogenerate up to date screenshots with playwright to put in the documentation. I'm pretty convinced that there
78.
by hitchstory 2y ago
I created a command line app for applying jinja2 to orgmode. I did it to scratch the itch of being able to generate pretty latex PDFs for my CV and for printed letters with content from my note taking app on my phone. I published it on pypi
79.
by hitchstory 2y ago
I built a Python/YAML framework around the ability to build these tests and then generate documentation from them. E.g. https://github.com/hitchdev/hitchstory/blob/master/examples%... which generate
80.
by hitchstory 2y ago
Screenshots was one thing that didnt work that I needed but I think lots of control characters used by command line apps also messed up pexpect. I built my own probably not very good equivalent of your thing called icommandlib. I'm goi
81.
by hitchstory 2y ago
I wrote an integration testing framework which I wanted to integrate with a tool exactly like this so it could be used to, e.g. test a command line app like vim. Expect is what I tried to integrate with first. It falls over quite quickly
82.
by hitchstory 2y ago
I built a testing and documentation framework to solve precisely this problem (google for my username to find it). You write the StrictYAML based tests structured according to your domain language/interactions and then you write one cl
83.
by hitchstory 3y ago
The "busy work" of low level unit tests is perfectly valid, but TDD still works extremely well with high level integration tests so I don't think a similar criticism necessarily applies.
84.
by hitchstory 3y ago
I built something like this too: https://github.com/hitchdev/hitchstory/blob/master/examples%...
85.
by hitchstory 3y ago
Thanks!
86.
by hitchstory 3y ago
Thanks, that's very helpful. 1 and 2 make perfect sense and are easy do demonstrate but 3 seems to me to be incredibly difficult. I haven't found an easy way to advertise convincingly to somebody who (quite reasonably) grants you
87.
by hitchstory 3y ago
BTW, odd question - assume somebody built a low/less code test automation framework that didn't fail and was very effective but it also wasn't popular. What could it do to stand out to you? What could it demonstrate in 15-20
88.
Show HN: Prompt Engineering Testing Framework(github.com)
2 points by hitchstory 3y ago|0 comments
89.
by hitchstory 3y ago
Not just how quickly it can be changed but how risky it is to change.
90.
by hitchstory 3y ago
If they include detailed plans and timelines for feature deliveries then yes.

More ›