Sponsoring improvements to the library

[venkatd]

Hi @hauleth

Do you offer open-source dev services? We are using watermelon in our backend and there are some improvements we'd like to make. Most of them are related to better error messages.

If you're interested, we can create some GH issues for you to take a look at. And I noticed you're setup with GitHub sponsors, so we could pay you directly through there.

Please let me know here or at venkat@turtleos.com. Whatever is more convenient for you :)

Cheers,
Venkat

[hauleth]

Sorry for delay. What are the things that you want to have there? Maybe open regular feature requests and I will try to find time to implement them. Any stuff about usability is pretty important for me, so if you have any suggestions, then I am fully open.

For sure the sponsorship is welcome, however right now I cannot promise any extra stuff. I am thinking about reworking my sponsorship page to include more options and details.

[venkatd]

CC-ing @rwillians who has been using this library for our tests

He has made some improvements in a fork so I'll let him jump into this discussion. Perhaps we can contribute some of those back. And later we could sponsor further improvements if you free up and have a good option for this.

[rwillians]

Hey @hauleth, I’m on mobile so I’ll just list the topics for improvements then during next week I can open individual issues for each one with more info

• Loading steps from other files only works when running all tests, when running a single test then elixir is unable to find the step module. That’s bc those modules weren’t compiled. This means you have to extract the steps you want tomahawk between features and put them on files place in a directory that the compilers is configure to compile on test env, such as test/support or a custom directory you may have configured. Alternatively you can require those files to be compiled manually. Seems tricky to solve that inside the lib and honestly, the lib probably shouldn’t solve that, but it can be documented;
• When you load steps from a file which has a “feature” defined, be it a feature file or as text, both the tests are executed (tests from the test file which imported the steps and tests from the file from which you imported the tests from). This has te potential for vasvade-running all tests in your application even tho you might just wanted to run tests form a single file. This implies, once again, for the current version of the lib, that user need to extract steps they want to share into a support file using only the DSL;
• As for error handling, when a test failed, I believe it should be printed: name of the failed scenario and all its steps, highlighting the failed one. Printing all steps has proven to be useful IME, be it for context, helping locating mistakes faster in local-env or even for being able to read the entire scenario without having to locate and open its feature file. I did implement a really crappy implementation for this cuz I was on a hurry, but the logged information was good enough for our case. I can share a print of it once I’m at my laptop.

I might be forgetting something, but I think this is the main stuff. I don’t have the time to prioritize this kinda of infrastructure code right now and the changes I made to the fork were just embarrassing crappy just to get us unblocked so I wouldn’t consider PRing that here, but we’d still want to see those improvements making their way upstream. That’s why we decided to reach out for sponsoring these improvements cuz, besides supporting your work, you might even find a better solution than what we were able to come up with.