Topics

• Q&A with Feanil Patel (Deactivated) 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)

  • 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 zs

    • For more discussion of this topic, see the draft OEP-37: https://github.com/edx/open-edx-proposals/pull/118

• 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.

• Recommendation:

  • 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

• Shopping cart deprecation - lessons learned, knowledge sharing on dead code, etc.