Skip to content

Alter binding source processing to no longer look for BindingAttribute#1044

Open
Code-Grump wants to merge 5 commits intomainfrom
feature/make-bindingattribute-optional
Open

Alter binding source processing to no longer look for BindingAttribute#1044
Code-Grump wants to merge 5 commits intomainfrom
feature/make-bindingattribute-optional

Conversation

@Code-Grump
Copy link
Contributor

@Code-Grump Code-Grump commented Feb 21, 2026

🤔 What's changed?

This changes the binding source processing to no longer look for the presence of a Binding attribute on the class. Now, simply using any of the binding attributes (step bindings, hooks, etc) is sufficient to trigger a class being treated as binding type.

⚡️ What's your motivation?

This change is in-keeping with most test frameworks to no longer require marker attributes at the class level, simplifying user code somewhat.

🏷️ What kind of change is this?

  • ⚡ New feature (non-breaking change which adds new behaviour)

♻️ Anything particular you want feedback on?

The changes made to the processor have been done in a way that should maintain backwards-compatibility at the contract. I would appreciate this being scrutinised for potential problems.

📋 Checklist:

  • I've changed the behaviour of the code
    • I have added/updated tests to cover my changes.
  • My change requires a change to the documentation.
    • I have updated the documentation accordingly.
  • Users should know about my change
    • I have added an entry to the "[vNext]" section of the CHANGELOG, linking to this pull request & included my GitHub handle to the release contributors list.

This text was originally taken from the template of the Cucumber project, then edited by hand. You can modify the template here.

@Code-Grump Code-Grump marked this pull request as ready for review February 23, 2026 19:41
return false;

var bindingSourceType = CreateBindingSourceType(type, filteredAttributes);
var candiateMethods = type.GetMethods(
Copy link
Member

@304NotModified 304NotModified Feb 23, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I’m curious about the performance impact — there could be many methods involved. In time and memory.

Creating a list for every type at least adds memory pressure, and reflection is relatively slow.

P.S. There’s a typo in “candidate”.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This definitely adds a cost for us - the system is written to produce a lightweight model layer between the actual reflection and the processing of binding methods, and without restructuring it more significantly, there's going to be allocations we could avoid.

However, I'd simply make the case that it's happening on a scale that's hard to perceive for most use-cases. This is the model that NUnit has used for a long time and that xunit has always used. If we'd like to make it as efficient as theirs, we'd need to do something more breaking in our APIs to refactor the component to yield types more efficiently.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good one about xUnit and NUnit. Im don't know if they use some kind of cache.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants