feat: Add FactoryBot instrumentation

[americodls]

Adds OpenTelemetry instrumentation for the FactoryBot gem to provide visibility into test data creation patterns during testing.

Subscribes to the factory_bot.run_factory ActiveSupport::Notifications event to capture all factory operations without monkey-patching. Supports FactoryBot 4.0+ and captures all factory strategies (create, build, build_stubbed, attributes_for) including batch operations (create_list, build_list, etc.).

Span naming: FactoryBot.{strategy}({factory_name})
Example: FactoryBot.build(user), FactoryBot.create_list(post)

Span attributes:

• factory_bot.strategy: Internal strategy name (build, create, stub, attributes_for)
• factory_bot.factory_name: Name of the factory being used
• factory_bot.traits: Comma-separated list of traits applied (if any)

[kaylareopelle]

Hi @americodls, thanks for opening this PR. Would you be interested in being a codeowner for this gem? That would involve reviewing PRs and issues related to the factory bot instrumentation. We don't have the codeowner behavior automated in GitHub, but we're currently documenting this in the CODEOWNERS file in the repo.

[americodls]

Hi @kaylareopelle! Happy to take it on 🙂
I've just updated the CODEOWNERS file — let me know if anything is needed!

[simi]

@americodls would you mind to share more how do you instrument testing also?

[thompson-tomo]

Suggestion name this test.data.strategy given it could be used elsewhere and we already have the test namespace?

[americodls]

Thanks for the feedback!

I checked the OpenTelemetry test semantic conventions and found that the test.* namespace currently only defines attributes for test execution metadata (test cases, suites, and their statuses).

Since test.data isn’t part of the spec yet, using it now could risk conflicts if it’s added later. The current factory_bot.* approach keeps things scoped to this library’s specific domain.

I’d suggest keeping the dedicated namespace for now — we can always generalize to something like test.data.* if similar fixture/factory patterns start appearing across other testing libraries. That way, we’re being intentional rather than speculative about the abstraction.

Of course, I’m open to other perspectives — input from the maintainers would be especially valuable given their broader experience in this space.

[thompson-tomo]

So perhaps the following helps defining attributes

When defining an attribute for a narrow use case, think about potential broader use cases. For example, if creating a system-specific attribute, evaluate whether other systems in the same domain might need a similar attribute in the future.

I see the attributes identified as falling into that category as anything generating data needs a strategy etc.

I would even suggest raising a pr to get the attributes/spans added.

[arielvalentin]

Although I agree with @thompson-tomo that we need to do our best to adhere to the spec for attribute naming; I am amenable to releasing custom attributes for our instrumentations since they are all pre-1.0 at this point and we are still working through figuring out how the version semantic conventions used in instrumentation libraries.

The factory bot use case seems very narrow since the spans are implementation specific. Other testing object mother or factory libraries will likely use different domain language based on DSLs and helper methods. We may find that higher level span names may have some overlap but library specific attributes like traits are likely not going to be a good fit for a "broader" use case.

@americodls Are there any other testing libraries that are currently instrumented in other languages?

Is there enough traction there to start up a conversation between SIGs?

[americodls]

@americodls Are there any other testing libraries that are currently instrumented in other languages?

Is there enough traction there to start up a conversation between SIGs?

I haven't found anything that's why I suggested to "go as is".

[thompson-tomo]

Suggestion name this test.data.traits given it could be used elsewhere and we already have the test namespace?

[thompson-tomo]

If test.data.* is adopted, I would add a test.data.provider.name attribute.

[americodls]

@americodls would you mind to share more how do you instrument testing also?

Something like this:

# spec/spec_helper.rb

#...

if ENV["ENABLE_TRACING"]
  require 'opentelemetry/sdk'
  require 'opentelemetry/instrumentation/rspec'

  OpenTelemetry::SDK.configure do |c|
    # ...
    c.use 'OpenTelemetry::Instrumentation::RSpec'
    c.use 'OpenTelemetry::Instrumentation::FactoryBot'
    # ...
  end
end

RSpec.configure do |config|
  #...
  config.after(:suite) do
    OpenTelemetry.tracer_provider.shutdown if ENV["ENABLE_TRACING"]
  end
  #...
end

[arielvalentin]

Thank you for your submission!

There are a few required changes you will have to make to avoid issues/conflicts with our release tooling.

I will have to reach out for help to other users who are FactoryBot users to help with a review before we merge.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: americodls / name: Américo Duarte (582dc09, aedabcb)

[arielvalentin]

@americodls there seems to be conflicts with upstream. Please merge main and we will proceed.

[arielvalentin]

@americodls thank you again for your submission.

Although I approved this PR, I am going to have request some additional changes.

Our CI workflows have changed and this gems test suite is not longer running by default.

You will need to add entries in the following actions workflow:

• opentelemetry-ruby-contrib/.github/workflows/ci-instrumentation-full.yml

  Line 8 in 1e01808

  paths: &path_filters

• opentelemetry-ruby-contrib/.github/workflows/ci-instrumentation-full.yml

  Line 67 in 1e01808

  gem:

In addition to that please add factorybot as a gem dependency in our canary install test:

opentelemetry-ruby-contrib/releases/Gemfile

Line 14 in 1e01808

gem 'faraday'

Thank you for your patience.

[americodls]

@arielvalentin

Thanks for your feedback!
I've gone ahead and fixed the issues you pointed out 🙂

Let me know if there’s anything else you’d like me to tweak!