this post was submitted on 31 Mar 2025
530 points (98.4% liked)

Funny

8832 readers
1738 users here now

General rules:

Exceptions may be made at the discretion of the mods.

founded 2 years ago
MODERATORS
TheDude@sh.itjust.works
kersploosh@sh.itjust.works
example@reddthat.com
VicksVaporBBQrub@sh.itjust.works
530
So, how's the job search going? (lemmy.world)
submitted 1 week ago by The_Picard_Maneuver@lemmy.world to c/funny@sh.itjust.works
53 comments fedilink hide all child comments
 
you are viewing a single comment's thread
view the rest of the comments
[–] JackbyDev@programming.dev 15 points 6 days ago (9 children)

Yes, I actually do. It's a behavioral driven testing framework. I love the idea of it but hate working with it because everyone uses it improperly.

What the steps in a scenario should look like:

Given a user has a bank accout
And the account has a balance of $10
When the user attempts to withdraw $20
Then the transaction should fail

How everyone I've worked with uses it:

Given the system is setup
Given the user TESTUSER1
Given load TESTDATA1
When the user sends a request
    ACTION | AMOUNT
    WITHDRAW | 20.0
The the response should be 400
    STATUS | MESSAGE
    Failure | Not enough funds
[–] sugar_in_your_tea@sh.itjust.works 1 points 5 days ago (6 children)

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.

[–] thirtyfold8625@thebrainbin.org 1 points 5 days ago (1 children)

I think there's one question you should answer in order to fully describe your "testing framework": is it being used for "end to end tests" or "integration tests" or "unit tests"? https://k-hartanto.medium.com/testing-pyramid-and-testing-ice-cream-cone-what-is-the-difference-6ddde3876c20

For unit tests, something like https://en.wikipedia.org/wiki/JUnit is useful. For testing a program after it's deployed, something like https://jbehave.org/reference/stable/story-syntax.html is useful. You get different information about your program from each type of testing, and one type can detect issues even if the other didn't, so doing both is useful.

[–] sugar_in_your_tea@sh.itjust.works 2 points 5 days ago

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.

load more comments (4 replies)
load more comments (6 replies)