nsdarren

It doesn't support OAuth2 yet, but I do plan to add more auth schemes in the future.

There's an experimental OpenAPI import function.

Thanks for your kind words!

Great feedback, thank you. I agree “Info” is probably clearer.

There are a couple of UX sharp edges to clear up for sure - a bit more validation, confirmations, etc to be added.

I agree that could be improved! The extra Vim keys you suggested should be simple enough to add.

Thanks for the feedback! It is actually intended that you create the collection yourself first, but I should perhaps make that clearer.

Hiding how to quit the app was just another attempt to win over the Vim crowd!

(Yes ctrl+c is the intended way, it’s in the docs now and I’ll add it to the app footer)

It’s iTerm 2

Thank you!

Thank you very much! It's definitely not feature complete yet - but I hope it can be a solid competitor in the space.

You'll be able to add custom themes pretty soon. Hopefully within the next couple of weeks.

There's no fallback to the ANSI theme of the terminal as it breaks a lot of Textual's features.

There is a PR open at the moment relating to detecting the terminal background colour I believe, so in the future we could probably use that to choose a reasonable fallback.

I'm going to explore integration with other formats in the future. Right now there's experimental (incomplete) support for importing from OpenAPI v3. I'd like to add Postman and Insomnia collection importing too. Some kind of integration with Hurl could be very nice too, but would likely come further down the line.

Thank you!

I had a look at the Bruno website for the first time a few weeks ago, although I haven't tried it for myself yet. I'm definitely inspired by and agree with a lot of the principles behind Bruno: local first, developer friendly, readable/Git-friendly collections and so on.

I think I share a lot of the same motivations as Bruno's creator - I feel the landscape of HTTP API testing clients may actually have regressed in recent years from a developer's perspective, as the companies behind Postman/Insomnia etc. figure out how to monetise them.

What's the point of this comment other than being snarky/attempting to show off? You should reflect on it, because this would be a better place if people like you just didn't bother replying.

Maybe you don't find it valuable because your setup and mad vi skills offer you an alternative (which I'm very sure is just as feature-rich as what is described in the post, which you didn't read). Isn't it obvious how a more accessible solution might be useful to some people?

I for one welcome the efforts of the Warp team to improve terminal UX.

Probably the closest thing would be to add a unique tag to each instance of the test:

  for lhs, rhs, res, tag in [
        (1, 1, 2, "thing1"),
        (2, 3, 5, "thing2"),
        (3, 4, 7, "thing3"),
  ]:
      @test("simple addition", tags=[tag])
        def _(left=lhs, right=rhs, result=res):
          assert left + right == result

You can then select individual tests using something like `ward --tags thing2` to only run tests with that tag (in my example, the 2nd of 3 tests).

Since multiple tests can share the same tag in Ward, if you wanted to narrow things down to ensure you're only selecting from the tests generated in this loop you could do something like `ward --search 'simple addition' --tags thing2`.

You can also select multiple instances at once with `ward --tags 'thing1 or thing3'`.

Thanks :) That's one of my biggest gripes with pytest too, and was one of the main things I was looking to solve.

I built Ward (https://github.com/darrenburns/ward), a Python test framework.

I have issues with the way the pytest fixture system works (parameter names matching function names), the readibility of the output, and some other things.

It started as a little learning experiment and has turned into something I've been building into what I hope will (and already is in some aspects) be a viable contender to pytest.

Author of Ward here! Thanks for the feedback. It's a common piece of feedback I hear and I do agree.

I haven't documented this yet, but due to the way Ward works you can actually write your tests inside a loop in order to parameterise them (see below). This is a little more explicit, and lets you build up your test data using things like itertools (if you like):

  for lhs, rhs, res in [
      (1, 1, 2),
      (2, 3, 5),
  ]:
      @test("simple addition")
      def _(left=lhs, right=rhs, result=res):
          assert left + right == result

I'm considering how/whether to add a pytest style decorator for parameterisation too.

If you give Ward a try or just have any other general feedback, please let me know if you have any issues/suggestions on GitHub.

I made a Python 3.6+ testing framework called Ward (https://wardpy.com/) that I hope can be a compelling alternative to pytest!

Quick overview of features:

* Describe your tests using strings instead of function names

* Fixtures that use the Python import system instead of name matching

* ~50% of the framework overhead of pytest

* Highly readable, colourful output including coloured diffs

* Support for parameterised testing

* Configurable with pyproject.toml, but has sensible defaults

* Ability to search for tests based on descriptions and test bodies

* Supports Linux, MacOS, and Windows

* Uses type hints!

* Hypothesis works out of the box, and soon fixtures will regenerate on each example

I'd love to hear any constructive feedback :)

If you're interested in this project, I'd love to see more contributions from the community. The codebase is relatively small at the moment!

Check out the site linked above or GitHub at https://github.com/darrenburns/ward - and feel free to ping me a message!