Type hinting: Do we want it? Everywhere or just in APIs? etc?
MFE with Luca follow-ups ?
React - Discussions Forum - editor input - draft JS
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 on Inter-service Eventing
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)
Factories will allow you to create fixture data
Code reuse with internal test class helper method
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 zs
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:
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.
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.
Business-logic validations: Validation at the edge (in higher-order API layers)
Database-level constraints: (such as uniqueness) should remain at the model