My SO and I don’t really decorate our house, so it’s mostly bare walls.

The delta between the losses in the S&P 500 and gains in SPAXX.

It absolutely did, at least for anything travel related.

I did a quick check and they’re definitely Canadian and recently went to CES. So I think “snows” is a given and “works in tech” is extremely likely.

I really hate looking at people’s post history though, so please don’t harass person.

Yeah, I don’t get it. The only people looking at the results are devs, so we really don’t need the business requirement text.

I could maybe understand if product owners were creating the requirements in the feature files and devs were implementing them in the code, but that never happens. So the whole cucumber library thing we have going on just feels annoying.

It’s not the only thing we over-engineer. We have dependency injection when we only ever have one dependency (except in tests, in which case we could just use mocking). We take microservices to the extreme (we just broke out a couple hundred lines of code from a few thosand lines of code service). Our test code is unnecessarily reusable (test code is one place where DRY doesn’t really need to apply). And so on. This one in particular is especially annoying because it makes it harder to find the code without providing much benefit.

Our QAs seem to like it, so whatever. I’ll still complain though.

Sure, and my issue isn’t that it’s capable of my requirements, but simple to use and meets those requirements. Simplicity is a quality all its own.

JUnit provides sufficient output to meet my requirements, so why overcomplicate it w/ Cucumber? AFAIK, cucumber tests in Java output JUinit as well (at least ours does), so what value exactly is Cucumber providing?

These are for a mix of end to end and integration tests.

I mostly do unit tests as a dev, so our tests are simple enough that they don’t benefit from more structure than being grouped by suite. E.g.:

• AuthService
  • valid user creds can login
  • invalid user creds cannot login
  • non-existent user gets same error as wrong creds
• UserSettingsService
  • can change language
  • cannot set empty password

These don’t have long flows, so there’s no benefit to documenting steps (they usually have one step).

My complaint about cucumber/gherkin isn’t with documenting steps, it’s with managing them in separate files. We have a Service.feature file that documents the scenario and the ServiceTest.java that documents the steps. I don’t see the point in having those be separate files, especially since the only people defining inputs and scenarios are the devs (dedicated QA in our case). We occasionally have our BE devs help write a few tests, and every time it’s a struggle for them to figure out where everything is. It just feels over-engineered.

In unit tests, we parameterize our tests just like with cucumber, we just do so in the code. E.g. in Python:

@parameterized.expand([(1, 2), (2, 4)])
def test_duplicate(num, exp):
    res = dup(num)
    assert res == exp

I would much prefer something like that in our end to end and integration tests.

Or maybe we just use it poorly. It doesn’t help that we use perhaps my least favorite language for testing: Java. I’ve written tons of integration tests, but we just used Python and unittest with some plugins to make output nicer, and it was pleasant enough.

I won’t tell you how to live your life.

Something is better than nothing, but keep looking.

I disagree. I’m a full-stack engineer, and every time I interact with our QA test suite in cucumber, I break out in hives. I hate keeping the gherkin feature file up to date with the test code, why so much complexity?

Demonstrate doing all three in the proper order. You get one cucumber.

Well yeah, cucumber is a Ruby/Java/etc testing framework and celery is a Python async task queue framework. Know what job you’re applying for, silly.

😁

Maybe that’s why I hate using it, or maybe I just hate testing frameworks that do more than run tests. Here’s what I want from a testing framework:

• run tests in classes or modules
• report output with some configurable name (javadoc comment, Python Docstring, etc)
• some way to parameterize tests with different inputs
• organized output that shows what failed
• if it’s an integration test, keep track of failures over time

Our QA uses cucumber and it works for them, so I only whine when I need to deal with it.

Sure, but how much does that actually happen?

Yeah, that would be rad. Some stores do that for water and peanut butter and whatnot, but I haven’t seen soap.

Sure, but that increases weight and cost. It’s certainly an option though.

I recommend inflating with hydrogen for even more bouyancy. Worst case scenario, it becomes a rocket and you achieve the same end result a little more quickly.

That depends on your vibrator. Always find a way to DIY, I say.

It obviously does. 😁