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 zs

    • For 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:

  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:

    • Business-logic validations: Validation at the edge (in higher-order API layers)

    • Database-level constraints: (such as uniqueness) should remain at the model