Testing framework requests

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

10 comments
Comment actions Permalink

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

>


0
Comment actions Permalink

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

0
Comment actions Permalink

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

0
Comment actions Permalink

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

>


0
Comment actions Permalink

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

0
Comment actions Permalink

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

>


0
Comment actions Permalink

Done in #898


Thank you!


Timur

0
Comment actions Permalink

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

0
Comment actions Permalink

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

>


0
Comment actions Permalink

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

>


0

Please sign in to leave a comment.