Using BDD with Python/Django

[bengineerdavis]

Synopsis:

Linda, Phil, and Ben are interested in expanding on using Behavior-Driven Development, a evolution of the test-driven (TDD) methodology, to create a Pull Request for a CodeBuddies/backend issue that will improve user registration for our new website by requiring an email. We'll be using the pre-existing backend API to implement this.

We'll synthesize our notes here, after (at least) 1 or more hangouts, working on this issue and pull request.

[BethanyG]

Additional discussions connected to this in #173. In particular, wanted to post this link to Automation Panda. Seems to have some really good stuff on PyTest and BDD: https://automationpanda.com/bdd/

[bengineerdavis]

Thanks Bethany!

[bengineerdavis]

For reference: the feature file we wrote.

Feature: Create views for the new Projects API Endpoint.

Some of these items may not need custom code, but are listed here as a reminder of what's needed:

Scenario: Create list and detail views for the endpoint.
# See the DRF ModelViewSet, DRF Generic Views and DRF CreateModelMixin for background and places to start.

Scenario: Add an ISAuthenticated permissions class to require a login for the endpoint.
# See Permissions in DRF

Scenario: Add search or filter backends as needed.
# See DB queries in Django, DRF Filter Backends, Filtering in DRF, and DRF SearchFilter for some background to start.

Scenario: Add search_fields for endpoint

Scenario: Add PATCH function to update records already in the DB

Scenario: Add perform create function as needed for specialized user lookup or other (e.g. many-to-many) relations.

Scenario: Add/define queryset for the list view of projects

Scenario: Add links to associated serializers

Tests(?)

On POST:

- For a given set of dummy data for the Projects model, return JSON string with all available projects.
- For a given set of dummy data for the Projects model, return JSON string for the Projects guid.

NOTES:
- Endpoints, test to check that each endpoint exists
- Test that a specific Projects endpoint gives back desired data/matches data we expect.
- Test that authenticated-only users can create a new project API endpoint.

- 'Evil user tests': test what happens if user deliberately breaks CRUD API actions on Projects Endpoints
- Write test in way that we know are going to fail, make a checklist_id?
- Confirm 200 server code for an api endpoint instance.

[lpatmo]

The user story Ben and I wrote the other day:

[lpatmo]

cc @watchtheblur

[lpatmo]

Decision record note: Ultimately we decided not to continue on the BDD path for testing the API. We'll continue making unit tests like in resources/tests.py!

[bengineerdavis]

Thanks @lpatmo for posting these!

[bengineerdavis]

I'll add: the User Story created by BDD create statements ('Given', 'When', 'Then') within Scenarios that could imply a whole sub-suite of unit tests, making it harder for us to determine what test we're running for each part of the Scenario and then locating the correct test(s) to run if something fails. Although, it seems like the frontend team is already applying this and using it in connection with UI/UX seems like the strongest application for this paradigm.