New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update v1 => v2 Migration Guide to talk about sealed TraitAttribute #498

Closed
bradwilson opened this Issue Jul 27, 2015 · 6 comments

Comments

Projects
None yet
1 participant
@bradwilson
Copy link
Member

bradwilson commented Jul 27, 2015

From @bradwilson on January 20, 2015 18:14

Copied from original issue: xunit/xunit.github.io#5

@bradwilson

This comment has been minimized.

Copy link
Member Author

bradwilson commented Jul 27, 2015

From @micdenny on January 22, 2015 19:18

What's the reason behind this? Why changing in sealed?

@bradwilson

This comment has been minimized.

Copy link
Member Author

bradwilson commented Jul 27, 2015

Test discovery in xUnit.net can happen without binaries (Resharper and CodeRush can discover tests as you type, by looking at the source code, even when that code doesn't necessarily compile).

In order to support this (not being able to run code), it requires that we seal the attributes, so that discovery can be based on things that are known only from the source, and not from running compiled code.

Let's take a common example: someone wants to make [Category("...")] which is the equivalent of [Trait("category", "...")]. Without a sealed attribute, you would write this:

public class CategoryAttribute : TraitAttribute
{
    public CategoryAttribute(string value) : base("category", value) { }
}

The problem is that Resharper or CodeRush cannot run this code, they can only look at the source. Simple examples like this may be possible, but it doesn't take long to come up with a scenario where it becomes non-trivial and the only recourse would be to run code and see what happens.

So the tradeoff we make here is to require a bit of known-to-be-compiled code which can inspect the [Category("...")] code and return the correct trait value(s). By sealing the attribute, it says that someone who wants to write CategoryAttribute also needs to write the discoverer that can make sense of what that means without being able to run the code in question.

We have an example which does exactly this: https://github.com/xunit/samples/tree/master/TraitExtensibility

@bradwilson

This comment has been minimized.

Copy link
Member Author

bradwilson commented Jul 27, 2015

From @micdenny on January 22, 2015 23:1

Thanks for this exhaustive explanation! Got it :)

@bradwilson

This comment has been minimized.

Copy link
Member Author

bradwilson commented Jul 27, 2015

That's like a beta of the doc page. 😀

@bradwilson

This comment has been minimized.

Copy link
Member Author

bradwilson commented Jul 27, 2015

From @micdenny on January 23, 2015 10:40

Thanks again @bradwilson and check this out 😄

How to extend/migrate TraitAttribute to XUnit v2 and why has become sealed

@bradwilson

This comment has been minimized.

Copy link
Member Author

bradwilson commented Nov 10, 2017

Closed for age.

@bradwilson bradwilson closed this Nov 10, 2017

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