With regard to patterns, I often find myself in the situation that I don’t fully understand and much less appreciate the pattern until I can explain why it is a better solution than a different pattern/style in a given situation.

Therefore, I would present examples that precisely don’t use dependency injection and let the audience point out concrete difficulties that these code snippets have (with regard to modularity, testability), etc.

As a concrete example, show code of the kind:

def sendMessage(msg):
  if len(msg) > 160:
    raise MessageTooLongException('message is longer than 160 chars')
  with TweetService() as tweetService: # needed to send the message
    tweetService.tweet(msg, API_KEY)

A good answer should point out that it is impossible to unit test this method without relying on Twitter’s services:

Obviously, if Twitter is down, your unit test would fail because the tweet method raises an exception even though your code is fine. If we were using DI, we could provide a mock TweetService object which allows to check whether the tweet call was made and the object disposed of correctly.

Providing negative examples has the advantage that it trains your audience to recognize such code as they write it and helps them to notice the benefits of DI in these situations right ahead.

I often try to transpose the principles of OOD/OOP into real-life situations, as OOP arose largely as a result of the need to infuse real-life models into programming. I don’t think DI is missing from our everyday lives. Take the humble charger for example, pick anyone (except the iPhone charger). A large majority of manufacturers default to the micro-usb form factor for charging points. The advantages

1. To the user, you can essentially use any charger with any mobile phone. Contrast this with the iPhone and the latest charging port debacle and the DI pretty much justifies itself

2. To the manufacturer, a single production line can cater for all the charging unit needs of their entire product line.

If your students can adequately transpose the DI principle into real-life scenarios, IMO, it’s a good reflection of their understanding of the principle

You could concentrate your comprehension questions on the practical consequences of DIP principle.

DIP is about minimizing dependencies from implementations in order to achieve some quality goal, so you could possibly give two small designs, one with client’s class dependency on an interface and one with direct dependency to the implementation.

Let your audience explain the advantages of using DIP with respect to different qualities, e.g. testability or maintainability.