You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If the service package is imported, due to the use of testing types in exported packages for testing, the std testing package is included in the final compiled binary. Due to the fact that types in testing carry methods, the linker is unable to elide inclusion of code from these types when reflect is linked (i.e. nearly always). The testing package's init functions are also all run at application start-up, resulting in unnecessary start lag.
This import path is illustrated so
To avoid this, the types that are exported for testing by other packages should be put in separate packages subordinate to the package that they serve, with only _test.go files importing those subordinate packages.
For example, extract builders.NewNopExporterConfigsAndFactories from "go.opentelemetry.io/collector/service/internal/builders" into a new "go.opentelemetry.io/collector/service/internal/builderstest" which is not exported by e.g. "go.opentelemetry.io/collector/service" except in its _test.go files (this is the only package of the three shown in the graph above that actually imports builders for that function). In fact, you already have a builders_test package where that could live without any issue.
The equivalent change would also be applied for builders.NewNopReceiverConfigsAndFactories, builders.NewNopProcessorConfigsAndFactories, builders.NewNopConnectorConfigsAndFactories, and builders.NewNopExtensionConfigsAndFactories.
I imagine that this pattern of putting testing code in consumed API exists in other package hierachies as well, so the same comments apply to those if they exist as well.
The text was updated successfully, but these errors were encountered:
Uh oh!
There was an error while loading. Please reload this page.
Component(s)
service
Describe the issue you're reporting
If the service package is imported, due to the use of testing types in exported packages for testing, the std testing package is included in the final compiled binary. Due to the fact that types in testing carry methods, the linker is unable to elide inclusion of code from these types when reflect is linked (i.e. nearly always). The testing package's init functions are also all run at application start-up, resulting in unnecessary start lag.
This import path is illustrated so
To avoid this, the types that are exported for testing by other packages should be put in separate packages subordinate to the package that they serve, with only _test.go files importing those subordinate packages.
For example, extract
builders.NewNopExporterConfigsAndFactories
from "go.opentelemetry.io/collector/service/internal/builders" into a new "go.opentelemetry.io/collector/service/internal/builderstest" which is not exported by e.g. "go.opentelemetry.io/collector/service" except in its _test.go files (this is the only package of the three shown in the graph above that actually imports builders for that function). In fact, you already have a builders_test package where that could live without any issue.The equivalent change would also be applied for
builders.NewNopReceiverConfigsAndFactories
,builders.NewNopProcessorConfigsAndFactories
,builders.NewNopConnectorConfigsAndFactories
, andbuilders.NewNopExtensionConfigsAndFactories
.I imagine that this pattern of putting testing code in consumed API exists in other package hierachies as well, so the same comments apply to those if they exist as well.
The text was updated successfully, but these errors were encountered: