internetarchive / arklet

ARK minter, binder, resolver
MIT License
21 stars 16 forks source link

Automated testing framework #2

Open PieterjanMontens opened 2 years ago

PieterjanMontens commented 2 years ago

Hello,

It would be great to add a testing framework to the project. Beyond Django unittests I suggest a behaviour-driven (BDD) component : Behave. There's an available Django integration, and has as main advantage that tests can be easily written, understood, and enhances code-reuse (which is a way to avoid test code rot).

What a simple test might look like :

Feature : Minting ark identifiers
  Scenario: Simple minting request
    Given we have a running arklet service
      When we mint an id for url "http://example.com/this_test_is_ok"
        Then we obtain an ARK id
        And it forwards to "http://example.com/this_test_is_ok"

(see behave documentation for more information)

If the suggestion is validated, I can work on a PR that implements testing (be it behave or unittests).

avdempsey commented 2 years ago

Thank you for raising this issue. I agree 💯%

Internally we typically use pytest with pytest-django, black, pylint, and either poetry or pip-tools. This project started as a weekend thing, but we're using it in production now and it could use the full treatment (many thanks for you getting the environment variable and docker config going!).

Does that set of tools work for you? Preference between poetry and pip-tools?

I haven't see behave before. Is the idea you can reuse "Given", "When", and "Then" blocks across multiple tests? That seems pretty cool. With pytest we reuse something like the "Given" blocks with pytest fixtures. Then in the test function bodies we'll often do a comment style with given/when/then sections.

My main goal with the testing is to facilitate easy updates. We could end up running this for decades at IA, I want to make it easy to keep up with Django releases (and minimize other dependencies along the way).

avdempsey commented 2 years ago

Of course, by my own goal of limiting dependencies, an argument could be made for just using Django's built-in testing facilities. My ideal is only requiring standard lib + Django for what we deploy (well, and the database driver).

PieterjanMontens commented 2 years ago

Absolutely !

I understand the long-term objective : let's keep it within django with pytest. The app has to provide a limited set of functionalities ("do one thing but do it well") : going full BDD would be a burden (I do recommend it for larger projects with multiple people which aren't all tech experts ;) )

I'm a poetry fan, I'll open an issue to discuss that part 👍

avdempsey commented 2 years ago

I'm working on getting tox set up with pytest. That way we can test arklet against a matrix of all supported Python and Django versions. Locally I'm using pyenv+tox+poetry, and that turns out to be a little bit of a learning opportunity getting all of that playing nicely.

avdempsey commented 2 years ago

The test suite is starting to take shape with #6. This adds poetry, pytest, pylint, and tox. The tox config tests arklet against the latest patch of each supported version of Django and Python, as well as the upcoming Django 4.1 and Python 3.11.

Next up is getting GitHub Actions working and increasing the test suite coverage.

avdempsey commented 2 years ago

GitHub Actions is running. Next is adding tox to GitHub Actions and completing the code coverage.