Member Avatar for estherschindler

If you made a list of "If I knew then (when I got started) what I knew now," what would you include?

  • 4 Contributors
  • 3 Replies
  • 489 Views
  • 6 Days Discussion Span
  • Latest Post Latest Post by wwwalker

Dani AI

Generated

Good prompt from — this thread already surfaces the big themes raised by , and (unclear success criteria, scope of tests, and delivery friction). Below are concrete, immediately usable techniques that build on those observations without re-stating them.

Turn requirements into executable examples you can run. Capture acceptance criteria as small, concrete scenarios (Given/When/Then) and automate them so the spec is also a test:

Feature: Save profile

  Scenario: authenticated user updates profile
    Given a user is authenticated
    When they submit valid profile data
    Then the profile is saved and a confirmation is returned

Keep unit tests tiny, deterministic and isolated so failures point to a single cause. Use fixtures and simple fakes rather than real networks or databases:

def test_save_profile(client, monkeypatch):
    monkeypatch.setattr('service.api.save_to_db', lambda data: True)
    resp = client.post('/profile', json={'name': 'Ann'})
    assert resp.status_code == 200
    assert resp.json['saved'] is True

Separate fast units from slower integration/acceptance runs in CI, and gate deploys on the higher-level checks. Example job split (GitHub Actions style):

jobs:
  unit:
    runs-on: ubuntu-latest
    steps:
      - run: pytest -m unit -n auto
  integration:
    needs: unit
    steps:
      - run: pytest -m integration

Practical troubleshooting: quarantine flaky tests, parallelize slow suites, use recording/cassettes for external APIs, and measure test value (how many regressions caught pre-release, mean time to detect). Finally, echoing : validate against the user-facing behaviour — but for safety-critical domains add independent verification and hazard analysis before shipping.

Recommended Answers

All 3 Replies

Member Avatar for JamesCherrill

Test early, test often

Every requirement document is (a) wrong and (b) incomplete

Member Avatar for rproffitt

Nod to JamesCherrill.

My work involved and still does getting products out of the engineering cycle and into the world or production.

One of our company's best methods for doing that is to produce or use what is known as "the user manual." If you read books you may find this method in "The HP Way." While HP in my opinion has lost their way since about 2000 what we learned is this: If the product functions exactly as described in the user manual then you may completed your engineering cycle.

This can upset the engineering staff so be sure to listen to their concerns so you don't put out a 737-MAX product. Fix those and try the test as you being the user.

The buyers and users don't care if variables are in camel case or not. They only care if the product does what it is supposed to do, is reliable, lasts a good time and maybe serviced later.

I'm going to offend many by writing this but I wish I'd used this method on more projects that were mired in a design, redesign loop.

commented: 737-MAX should have had its GUI tested before shipping. It was a tragedy that 2 planes had to crash before they grounded the plane. +2
Member Avatar for wwwalker

Do unit testing. Only test one small module at a time. Once that passes, do unit test of next small module that relates to the first module. By process of elimination a very large set of programs can be tested thoroughly this way.

Testing is never complete. There is always something that was not tested.

commented: The 737-MAX story is one that we should have on its own. Was not a GUI problem. +15
Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.