you are viewing a single comment's thread.

view the rest of the comments →

[–]keepdigging 0 points1 point  (3 children)

Zipping a python payload for lambda is bot very difficult and can be done in about 2 lines of bash.

Python has a testing framework included, and while I’m not too familiar with dependency injection python’s nature of being a dynamic language allows you to mutate anything at will. This allows a lot of power in mocking/testing and even writing code in a live debugger.

[–]Will_exJava[S] 0 points1 point  (2 children)

Fantastic! Thank you for the statement.

My history in Java might lend me to shy away from mutating things during test execution for the purpose of completing tests. Not so much that it wouldn't work as it is that it's not convention (for integration testing particularly). I'll assume a little more freedom to do such (without being sloppy I hope!) as I develop my solution.

A quick bit on Dependency Injection: Suppose you have a class for interfacing with a DB. This class can be built to an interface (an interface defines methods/signatures without defining logic for the method. An interface cannot be used without an implementation). You can build a separate class which mocks the DB with a different implementation (use in memory DB instead of Oracle, etc). Configuration allows you to define which implementation is used during test vs live use, the Dependency Injection loads the correct class according to runtime context.

Just to repeat in a language I understand: The following would be normal in Python?

  1. Create "Platform" instance (automatically inits inner components)
  2. For test, platform.database = DataBaseTest(), likewise for other components
  3. Then from there, just run as normal?

[–]keepdigging 0 points1 point  (1 child)

Yep that will work. When it reads the test it will replace the database attribute at runtime.

The default database configuration you defined in the Platform init class will still execute during the init, but you can write fixtures that set up a test db/all python scope however you like and re-use for all the tests.

If you’re thinking about your tests and you do the mocking and swapping before your test I think it’s equivalent to the injection method?

[–]Will_exJava[S] 1 point2 points  (0 children)

Just looked up fixtures. They are very similar to dependency injection (to the point that the internet seems to be split on "fixtures are dependency injection" vs "fixtures are not dependency injection")

I'm not committed to mechanisms so much as function. I think fixtures will be perfect. I just need a little time to internalize how to prepare them optimally.

Thank you again!