Auto import feature

[borisbrodski]

In Xtend I miss some kind of auto-import of the static extensions. For example, I always import the Matchers and my personal collection of Xtend extensions.

This could be done by defining some kind of annotation of the one of the base classes. Something like this:

@XtendAutoImport({"my.cool.extensions"}, static = true, extension = true) class AbstractTest { }

For this to work, you will need a way to extend test classes from this AbstractTest or add it with the JUnit-Rule.

[sebastianbenz]

This looks to me like a tooling problem and not like a problem that should be solved on language level. I would prefer a solution similar to how Favorites work in JDT. This would then also belong into Xtend.

On Sep 24, 2012, at 4:34 PM, Boris Brodski wrote:

In Xtend I miss some kind of auto-import of the static extensions. For example, I always import the Matchers and my personal collection of Xtend extensions.

This could be done by defining some kind of annotation of the one of the base classes. Something like this:

@XtendAutoImport({"my.cool.extensions"}, static = true, extension = true) class AbstractTest { }

For this to work, you will need a way to extend test classes from this AbstractTest or add it with the JUnit-Rule.

— Reply to this email directly or view it on GitHub.

[borisbrodski]

You are actually right. But this Favorites feature (in java) is a global one. No context can be assigned one or another class being imported. The Annotation (or comparable) solution would provide the right extension methods to the right place (supporting the software design).

Currently this can be achieved by defining "final protected" methods withing the AbstractTest class. But since the java doesn't support the multiple inheritance, this solution is quite limited.

If you familiar with ruby, you can compare it with the modules, that can be included into the classes.

[sebastianbenz]

The favorites feature in Java is not global, as it is aware of the classpath. If you have org.hamcrest.Matchers in your favorites, they will be only proposed if org.hamcrest is on the classpath. Couldn't you just use extension fields if you want to have a more fine grained level of control?

On Sep 24, 2012, at 4:59 PM, Boris Brodski wrote:

You are actually right. But this Favorites feature (in java) is a global one. No context can be assigned one or another class being imported. The Annotation (or comparable) solution would provide the right extension methods to the right place (supporting the software design).

Currently this can be achieved by defining "final protected" methods withing the AbstractTest class. But since the java doesn't support the multiple inheritance, this solution is quite limited.

If you familiar with ruby, you can compare it with the modules, that can be included into the classes.

— Reply to this email directly or view it on GitHub.

[borisbrodski]

I could, but the extension fields doesn't get inherited, or am I wrong?

[sebastianbenz]

I don't really see a difference between:

@extend(typeof(AbstractTest)) describe "Something"{ ... }

and

describe "Something"{ extension AbstractTest = new AbstractTest }

Am I missing something? The advantage of the latter is that you could even have multiple helper classes.

On Monday, 24. September 2012 at 18:23, Boris Brodski wrote:

I could, but the extension fields doesn't get inherited, or am I wrong?

— Reply to this email directly or view it on GitHub (https://github.com/bmwcarit/Jnario/issues/36#issuecomment-8824892).

[borisbrodski]

Sorry for the long post...

The advantage of the latter is that you could even have multiple helper classes

This is exactly the problem I have. I not only can but I must specify many different extensions in each test class. So each time I write a test I have to write:

describe "Something"{ extension Extension1 = new Extension1 extension Extension2 = new Extension2 extension Extension3 = new Extension3 ...

}

(Code templates is not a solution. It is nearly impossible to ensure, that all team members have the same template configuration :-) )

I would like to bundle those extensions within a specified AbstractXxxTest class. For example, I have

• Unit tests
• Persistent test (mocking foreign APIs but using the real DB-connection)
• Integration tests

For each of those test types I defined an abstract test class. In those test classes I would like to add all extension methods, that make sense within the corresponding context:

• Unit tests: \ JMockit extensions, RandomProvider extension, DateTime extensions
• Persistent tests \ JMockit extensions, RandomProvider extension, DateTime extensions + DB-extensions (e. g. DB-Cleaner), Transaction managment
• Integration tests \ RandomProvider extension, DateTime extensions, JBoss connector, Login/Logout extension

The abstract classes could be JUnit rules, of cause, but this doesn't solve my main problem:

• Automatically provide the right set of the Xtend-extensions to the each of my test classes.

[sebastianbenz]

The only solution I see for you problem is to create for each of your use cases a specific extension class. But I don't really see a way how to solve this problem in Jnario. Autoimport would be cool, but only as an editor feature. However, this would belong to Xtend and I would recommend creating a feature request for Xtend instead.