Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cleanup tests, add support for error and pending payment statuses #20

Merged
merged 13 commits into from Oct 7, 2015

Conversation

maiksprenger
Copy link
Member

We ran into a bug where a payment status of ERROR was not handled by django-oscar-adyen, and we realized that a payment status of PENDING also isn't supported. To properly test for this, I went on a bit of a rampage to first clean up tests and a bit of actual code. The only "real" changes should be the two "Handle XX status notifications from Adyen" commits.

Reviewing commit by commit is recommended.

As I like to keep things simple, I removed one layer of inheritance. The
test case was pretty useless, as it mostly served to set settings that we
could set like any other Django setting already.
Conceptually, that's a totally different phase of the Adyen flow. As
they're a bit noisy, I've moved them to their own module.
The response tests deserved their own module. And with that, the
remaining tests were only testing payment notifications, so the
previously catch-all 'test_adyen' module was renamed.
It was easy to make those tests a bit easier to read, so I did. Also
removed a switch based on the Python version, because we only support
Python 3 anyway.
Woops, I called responses what are really redirects; the class is called
PaymentRedirection after all.
It only added an unneeded level of redirection and was only used when
being inherited from again by FormRequest. It might make sense to factor
it out later when adding another request class, but as it stands, it
just makes things harder to understand.
This commit moves some duplicate attributes to the common BaseInteraction
and removes one level of inheritance between PaymentFormRequest and
BaseInteraction.
This commit

* switches to using a MockRequest class instead of passing around
  weird state on self
* moves one-time-only data into the individual tests
* creates a dedicated module for unit tests
* uses py.test syntax and Django foo to make tests more readable
I was bothered by params.get(self.HASH_FIELD) because I'd expect the
hash field to always be present. But I realized it's better to allow it
not being present, but loudly raising an InvalidTransactionException,
irrespective whehter self.hash() returns anything or not (which it might
not do accidentally).

This is probably minor nitpicking, but better be safe than sorry!
The point of this PR really is to address a bug with ERROR notifications
from Adyen. Oscaro employees can check Sentry:
http://sentry-prod.oscaro.com/oshop/oshop-prod/group/1310/events/3457809/

The bug is two-fold. Error messages were forgotten in the status map.
Note that PAYMENT_RESULT_ERROR is already present in the codebase.

The other issue was that the lookup in ADYEN_TO_COMMON_STATUSES
was implemented to be forgiving (using get()). Hence the
traceback above is somewhat subtle; it lead to status being returned
as None.
As documented, Adyen may return a payment status of pending. This commit
adds support of it. As the job of django-oscar-adyen is merely to bubble
that data up to the Scaffold, the change is pretty simple.
This PR improved upon the tests, but there's always work left to do.
This commits adds a few of my ramblings about how we could improve
further.
@maiksprenger
Copy link
Member Author

I just verified locally that with this code, oshop doesn't choke on pending payments.

@aaugustin
Copy link

Looks good. Just one comment.

maiksprenger added a commit that referenced this pull request Oct 7, 2015
Cleanup tests, add support for error and pending payment statuses
@maiksprenger maiksprenger merged commit 1cab2a6 into master Oct 7, 2015
@maiksprenger maiksprenger deleted the feature/error-notifications branch October 7, 2015 12:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants