Testing framework requests

1. In addition to the existing methods that can throw assertion errors

(e.g. checkResultByText()) can you add methods with the same signature but
with an additional first String 'message' parameter just like JUnit assert
methods.
Quite easy.

2. Ability to specify (somehow) different mock jdks for the tests.

Not that easy since project is being set up once per all test in suite and
jdk is assigned at the same time. So you won't be able to change jdk on per
test basis. Anyway you wouldn't like it since setting up jdk may take some
significant (in terms of unit testing) time. BTW why you need it?

--

Best regards,
Maxim Shafirov
JetBrains, Inc / IntelliJ Software
http://www.intellij.com
"Develop with pleasure!"


"Timur Zambalayev" <no_mail@jetbrains.com> wrote in message
news:27379313.1060886821968.JavaMail.itn@is.intellij.net...

First of all, the testing framework works just great. Thanks!

>

Requests.

>

1. In addition to the existing methods that can throw assertion errors

(e.g. checkResultByText()) can you add methods with the same signature but
with an additional first String 'message' parameter just like JUnit assert
methods.
>

2. Ability to specify (somehow) different mock jdks for the tests.

>
>

Timur

>

2. Ability to specify (somehow) different mock jdks

for the tests.
Not that easy since project is being set up once per
all test in suite and
jdk is assigned at the same time. So you won't be
able to change jdk on per
test basis. Anyway you wouldn't like it since setting
up jdk may take some
significant (in terms of unit testing) time. BTW why
you need it?

That's fine (having additional test suite(s) with the overhead - currently it's 3-4 seconds in my setup for a small mock jdk). I want to test against different jdks (1.3, 1.4, 1.5 (ea)). In a plugin I'm testing the availability of some jdk methods. Anyway, I'm going to release the first version of the plugin today and you'll be able to see the use case.


Timur

2. Ability to specify (somehow) different mock jdks

for the tests.
Not that easy since project is being set up once per
all test in suite and
jdk is assigned at the same time. So you won't be
able to change jdk on per
test basis. Anyway you wouldn't like it since setting
up jdk may take some
significant (in terms of unit testing) time. BTW why
you need it?

Another possible reason: different projects may require mock jdks of different complexity. Now you have to use the most complex mock jdk and as a result you have more overhead.


Timur

What about something like
System.getProperty("idea.testingFramework.mockJDKPath") ?

--

Best regards,
Maxim Shafirov
JetBrains, Inc / IntelliJ Software
http://www.intellij.com
"Develop with pleasure!"


"Timur Zambalayev" <no_mail@jetbrains.com> wrote in message
news:13192403.1061041677344.JavaMail.itn@is.intellij.net...

2. Ability to specify (somehow) different mock jdks

for the tests.
Not that easy since project is being set up once per
all test in suite and
jdk is assigned at the same time. So you won't be
able to change jdk on per
test basis. Anyway you wouldn't like it since setting
up jdk may take some
significant (in terms of unit testing) time. BTW why
you need it?

>

Another possible reason: different projects may require mock jdks of

different complexity. Now you have to use the most complex mock jdk and as a
result you have more overhead.
>
>

Timur

>

What about something like
System.getProperty("idea.testingFramework.mockJDKPath"
?

Using a system property for determining from where to load the mock jdk for a test suite? Yes, I think it should be fine.


Timur

Done in #898

--

Best regards,
Maxim Shafirov
JetBrains, Inc / IntelliJ Software
http://www.intellij.com
"Develop with pleasure!"


"Timur Zambalayev" <no_mail@jetbrains.com> wrote in message
news:6341959.1061043279436.JavaMail.itn@is.intellij.net...

What about something like
System.getProperty("idea.testingFramework.mockJDKPath"
?

>

Using a system property for determining from where to load the mock jdk

for a test suite? Yes, I think it should be fine.
>
>

Timur

>

Done in #898

Thank you!


Timur

1. In addition to the existing methods that can

throw assertion errors
(e.g. checkResultByText()) can you add methods with
the same signature but
with an additional first String 'message' parameter
just like JUnit assert
methods.
Quite easy.

Did you decide not to add the methods?


Timur

Just missed this.

--

Best regards,
Maxim Shafirov
JetBrains, Inc / IntelliJ Software
http://www.intellij.com
"Develop with pleasure!"


"Timur Zambalayev" <no_mail@jetbrains.com> wrote in message
news:32892970.1061938114413.JavaMail.itn@is.intellij.net...

1. In addition to the existing methods that can

throw assertion errors
(e.g. checkResultByText()) can you add methods with
the same signature but
with an additional first String 'message' parameter
just like JUnit assert
methods.
Quite easy.

>

Did you decide not to add the methods?

>
>

Timur

>

Done in #915.

--

Best regards,
Maxim Shafirov
JetBrains, Inc / IntelliJ Software
http://www.intellij.com
"Develop with pleasure!"


"Timur Zambalayev" <no_mail@jetbrains.com> wrote in message
news:32892970.1061938114413.JavaMail.itn@is.intellij.net...

1. In addition to the existing methods that can

throw assertion errors
(e.g. checkResultByText()) can you add methods with
the same signature but
with an additional first String 'message' parameter
just like JUnit assert
methods.
Quite easy.

>

Did you decide not to add the methods?

>
>

Timur

>