Arch Tea Time: 2020-08-20

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