Giorgio Salluzzo

Mocket is normally used in situations like: ```python import aiohttp import pytest from mocket import mocketize @mocketize def test_a(): ... @mocketize def test_b(): ... ``` That's the use-case I am...

Even when in control, Mocket lets the real traffic pass, so nothing breaks. In your non-decorated test, you'd have real socket/context instances doing their normal job.

Let me write down a real example mimicking what you have in mind and come back to you.

You were right, and now that I read again the previous implementation I understand why. It was simply something that we never noticed. So, previously that use-case was broken (normally...

As a monkey-patch, people could pass a fake `SSLContext` when performing HTTP calls. Something like: ```python async with aiohttp.ClientSession( timeout=aiohttp.ClientTimeout(total=3) ) as session, session.get(url, ssl=FakeSSLContext()) as response: response = await...

An alternative I don't particularly like - client logic inside Mocket - would be mocking `TCPConnector._get_ssl_context`, but the function would have to be at module level to make it easier....

In the end I opted for the third approach, implementing a Mocket `TcpConnector` to be used with `ClientSession` when running tests. ```python class MocketTCPConnector(TCPConnector): """ `aiohttp` reuses SSLContext instances created...

[Mocket 3.13.2](https://pypi.org/project/mocket/3.13.2/) introduces the above `connector`. Here is a working test showing there is no need to import `aiohttp` when Mocket is in control: https://github.com/mindflayer/python-mocket/blob/main/tests/test_asyncio.py#L49 Thanks for helping.

Hi @git-staus, now I guess you understand what I meant when I said nobody is really actively contributing here. Feel free to take the lead with this and do what...

> It's still in the pipeline! Not sure why a couple of job didn't run. Now it's all done, sorry about that.