...
Backlog of Questions/Discussions
Type hinting: Do we want it? Everywhere or just in APIs? etc?
MFE with Luca follow-ups ?
React - Discussions Forum - editor input - draft JS
Open edX
joining us at 1x a month Arch Tea
Shared slack channels
Shopping cart deprecation - lessons learned, knowledge sharing on dead code, etc.
Q&A with Feanil Patel (Deactivated) on Inter-service Eventing
Topics
What does a good django set of unit tests look like?
Is there a better way to set up test states w/o creating objects in the test itself? (e.g. test case with 0 rows, test cases with 1 row / multiple states, test cases with 2 rows / one state)
Options
Factories will allow you to create fixture data
Code reuse with internal test class helper method
Pytest
Allows us to create tests without requiring them to me test methods in a Test class.
Also has fixtures - but won’t allow you to use Django’s Test SavePoints
Django’s Test case - allows auto rollback of database transactions for TestCase classes and savepoints for test methods in them
Aside: now that we're standardized on pytest, you can use the built-in
assert
keyword instead of the java-esque self.assertEqual(...) methods before: self.assertEqual(x, y) ; self.assertIn(z, zs) after: assert x == y; assert z in zsFor more discussion of this topic, see the draft OEP-37: https://github.com/edx/open-edx-proposals/pull/118
Thoughts on sending all Segment events across all repos into one NR table? (Discussed with Robert + Diane earlier today, curious if other people had opinions/thoughts)
Retaining the source of the event will
give us the richer information that we’ll eventually need to distinguish events.
allow us to mitigate name collision issues.
What kinds of validations/validation patterns do we use on Django models (if any?) Per Django docs:
Code Block Note that full_clean() will not be called automatically when you call your model’s save() method. You’ll need to call it manually when you want to run one-step model validation for your own manually created models.
...
- Shopping cart deprecation - lessons learned, knowledge sharing on dead code, etc.
DB validation isn’t always an option & model validations don’t seem to be guaranteed either
Django distinguishes between UI-level model validation versus Data model validation
Q: Should we override our save() methods?
Depends on whether the validation needs to happen only for certain paths or not.
For things that always need to be validated, can be validated via save.
Note: some docs recommend against this in order to avoid duplication of validation checks (both in save and in validators).
Note: A lot of our validation today happens in DRF serializers.
Recommendation:
Business-logic validations: Validation at the edge (in higher-order API layers)
Database-level constraints: (such as uniqueness) should remain at the model
Thoughts on sending all Segment events across all repos into one NR table? (Discussed with Robert + Diane earlier today, curious if other people had opinions/thoughts)
Retaining the source of the event will
give us the richer information that we’ll eventually need to distinguish events.
allow us to mitigate name collision issues.
Type hinting: Do we want it? Everywhere or just in APIs? etc?
MFE with Luca follow-ups ?
React - Discussions Forum - editor input - draft JS
Open edX
joining us at 1x a month Arch Tea
Shared slack channels