testing: add in-memory metrics exporter

[codeboten]

Adding InMemoryMetricsExporter to help with unit-tests, as part of the change i'm also adding meter_provider and memory_metrics_exporter to TestBase

[mauriciovasquezbernal]

Thanks a lot for these changes, those are quite useful.

I think we should split up the TestBase currently the class has some specific logic for tracing, check_span_instrumentation_info and I think in the future there will more, like checking parent-child relationship for instance.

I think there should be a common TesBase class that inherits from unittest.TestCase, then we could have TestBaseTracer, TestBaseMetrics. What do you think?

[mauriciovasquezbernal]

What do you think about implementing the shutdown method as well?

[codeboten]

I thought about it, but it wasn't clear to me what shutdown would be used for yet.

[mauriciovasquezbernal]

I think it's just a matter of completeness, it could help to find bugs if an implementation is calling shutdown by mistake, because it'll reject further calls to export.

[codeboten]

done

[codeboten]

I think there should be a common TesBase class that inherits from unittest.TestCase, then we could have TestBaseTracer, TestBaseMetrics. What do you think?

I can imagine how this will be useful in the future, but I'm also not sure how much TestBaseTracer and TestBaseMetrics will have in common.

[mauriciovasquezbernal]

Probably not much, I can imagine very generic helpers like:

opentelemetry-python/tests/util/src/opentelemetry/test/test_base.py

Lines 65 to 73 in 0889895

	@staticmethod
	@contextmanager
	def disable_logging(highest_level=logging.CRITICAL):
	logging.disable(highest_level)
	try:
	yield
	finally:
	logging.disable(logging.NOTSET)

[lzchen]

Seems like self._stopped isn't being used for anything? I believe in the span exporter it is used as a check upon calling export.

[codeboten]

added the check to export, as is done in the InMemorySpanExporter

[toumorokoshi]

Thanks a lot for these changes, those are quite useful.

I think we should split up the TestBase currently the class has some specific logic for tracing, check_span_instrumentation_info and I think in the future there will more, like checking parent-child relationship for instance.

I think there should be a common TesBase class that inherits from unittest.TestCase, then we could have TestBaseTracer, TestBaseMetrics. What do you think?

This would be cool, and I think this is precisely why we need to add pytest fixtures. It is not possible easily compose fixture setup / teardown using classes, so the join of the two will require careful coding to perform correctly (calling all base classes' setup and teardown methods).

[toumorokoshi]

I think a quick decision on export() and Leighton's note about the unused _stopped variable and I'm happy to approve. Thanks!

[lzchen]

LGTM

[toumorokoshi]

Thanks!