how to create new junit test

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

how to create new junit test

Ari Kast
Hi all

I'm doing some work inside org.eclipse.swt.custom.StyledTextRenderer to improve the cache hit ratio for the "layouts" field, and I wanted to write test cases for my work.

I didn't see an existing test class so I copied org.eclipse.swt.tests.junit.Test_org_eclipse_swt_custom_StyledText.java and created  org.eclipse.swt.tests.junit.Test_org_eclipse_swt_custom_StyledTextRenderer.java

To my surprise though, at the top of the test class when I import org.eclipse.swt.custom.StyledTextRenderer, some Eclipse rule seems to kick in and immediately delete my import statement.

What is the correct place and way to write JUnit tests for this class?

Thanks
Ari

_______________________________________________
jdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: how to create new junit test

Lars Vogel-2
Hi Ari,

Sounds like you are doing platform development, please use eclipse-dev mailing list in this case.

I think in SWT the save actions remove unused import statement and add new used once if required. So if you are using the imports they should not be remove. 

Hth. 

Looking forward to your performance improvement Gerrits. :-)

Best regards, Lars

Ari Kast <[hidden email]> schrieb am Do., 18. Juni 2020, 21:25:
Hi all

I'm doing some work inside org.eclipse.swt.custom.StyledTextRenderer to improve the cache hit ratio for the "layouts" field, and I wanted to write test cases for my work.

I didn't see an existing test class so I copied org.eclipse.swt.tests.junit.Test_org_eclipse_swt_custom_StyledText.java and created  org.eclipse.swt.tests.junit.Test_org_eclipse_swt_custom_StyledTextRenderer.java

To my surprise though, at the top of the test class when I import org.eclipse.swt.custom.StyledTextRenderer, some Eclipse rule seems to kick in and immediately delete my import statement.

What is the correct place and way to write JUnit tests for this class?

Thanks
Ari
_______________________________________________
jdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev

_______________________________________________
jdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: how to create new junit test

Mickael Istria-5
In reply to this post by Ari Kast
Hi,

On Thu, Jun 18, 2020 at 9:26 PM Ari Kast <[hidden email]> wrote:
I'm doing some work inside org.eclipse.swt.custom.StyledTextRenderer to improve the cache hit ratio for the "layouts" field, and I wanted to write test cases for my work.

Did you open a bug on bugs.eclipse.org about this work? It would improve collaboration opportunities.

To my surprise though, at the top of the test class when I import org.eclipse.swt.custom.StyledTextRenderer, some Eclipse rule seems to kick in and immediately delete my import statement.

If this StyledTextRenderer type isn't used anywhere in the code, the import is just cleaned up.
Also, the StyledTextRenderer is "package" visible only, so it's not really possible to interact with it from the tests bundle.. So please open a bug with more details about what you're trying to achieve and we'll discuss there what's doable.

Cheers,

_______________________________________________
jdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: how to create new junit test

Ari Kast
Thanks Lars and Mickael,

I submitted a bug for the behavior I'm investigating here https://bugs.eclipse.org/bugs/show_bug.cgi?id=564448

My thought was to change the "layouts" field to some kind of circular buffer or something that's more agnostic about the direction in which it grows -- or maybe even just a simple hashmap with a bit of decoration to prevent it from growing larger than CACHE_SIZE, and an eviction policy that calls dispose() when something gets replaced.  One way or another I'd like to find a way to keep that cache full, which I assume would yield benefits beyond just this one bug (for example currently typing one letter into a 200-tall block selection takes abt 45 seconds on my machine, so I'd like to see what impact this has on that and then investigate that further assuming it's still slow after this fix).

Is it preferable to write my own cache utility as opposed to using 3rd party libs?

BTW I tried first sending this reply to the suggested eclipse-dev mailing list but I think that message has been awaiting moderator approval for several days now. 

Thanks for any tips/suggestions/guidance.

Ari


On Thu, Jun 18, 2020 at 3:53 PM Mickael Istria <[hidden email]> wrote:
Hi,

On Thu, Jun 18, 2020 at 9:26 PM Ari Kast <[hidden email]> wrote:
I'm doing some work inside org.eclipse.swt.custom.StyledTextRenderer to improve the cache hit ratio for the "layouts" field, and I wanted to write test cases for my work.

Did you open a bug on bugs.eclipse.org about this work? It would improve collaboration opportunities.

To my surprise though, at the top of the test class when I import org.eclipse.swt.custom.StyledTextRenderer, some Eclipse rule seems to kick in and immediately delete my import statement.

If this StyledTextRenderer type isn't used anywhere in the code, the import is just cleaned up.
Also, the StyledTextRenderer is "package" visible only, so it's not really possible to interact with it from the tests bundle.. So please open a bug with more details about what you're trying to achieve and we'll discuss there what's doable.

Cheers,
_______________________________________________
jdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev

_______________________________________________
jdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: how to create new junit test

Daniel Megert
Hi Ari

Please try again with eclipse-dev or even better platform-dev. I can see a message from you on eclipse-dev: https://www.eclipse.org/lists/eclipse-dev/msg11420.html. I also verified that the moderator queue is empty.

Dani



From:        Ari Kast <[hidden email]>
To:        "Eclipse JDT general developers list." <[hidden email]>
Date:        22.06.2020 05:35
Subject:        [EXTERNAL] Re: [jdt-dev] how to create new junit test
Sent by:        [hidden email]




Thanks Lars and Mickael,

I submitted a bug for the behavior I'm investigating here https://bugs.eclipse.org/bugs/show_bug.cgi?id=564448

My thought was to change the "layouts" field to some kind of circular buffer or something that's more agnostic about the direction in which it grows -- or maybe even just a simple hashmap with a bit of decoration to prevent it from growing larger than CACHE_SIZE, and an eviction policy that calls dispose() when something gets replaced.  One way or another I'd like to find a way to keep that cache full, which I assume would yield benefits beyond just this one bug (for example currently typing one letter into a 200-tall block selection takes abt 45 seconds on my machine, so I'd like to see what impact this has on that and then investigate that further assuming it's still slow after this fix).

Is it preferable to write my own cache utility as opposed to using 3rd party libs?

BTW I tried first sending this reply to the suggested eclipse-dev mailing list but I think that message has been awaiting moderator approval for several days now. 

Thanks for any tips/suggestions/guidance.

Ari


On Thu, Jun 18, 2020 at 3:53 PM Mickael Istria <mistria@...> wrote:
Hi,

On Thu, Jun 18, 2020 at 9:26 PM Ari Kast <arikast@...> wrote:
I'm doing some work inside org.eclipse.swt.custom.StyledTextRenderer to improve the cache hit ratio for the "layouts" field, and I wanted to write test cases for my work.

Did you open a bug on bugs.eclipse.orgabout this work? It would improve collaboration opportunities.

To my surprise though, at the top of the test class when I import org.eclipse.swt.custom.StyledTextRenderer, some Eclipse rule seems to kick in and immediately delete my import statement.

If this StyledTextRenderer type isn't used anywhere in the code, the import is just cleaned up.
Also, the StyledTextRenderer is "package" visible only, so it's not really possible to interact with it from the tests bundle.. So please open a bug with more details about what you're trying to achieve and we'll discuss there what's doable.

Cheers,

_______________________________________________
jdt-dev mailing list

[hidden email]
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jdt-dev_______________________________________________
jdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jdt-dev



_______________________________________________
jdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: how to create new junit test

Ari Kast
Thanks Daniel!  My mistake, I thought I'd get a confirmation once it was approved -- still learning how things work here.  Will use eclipse-platform going forward.

Thanks
Ari

On Mon, Jun 22, 2020 at 4:07 AM Daniel Megert <[hidden email]> wrote:
Hi Ari

Please try again with eclipse-dev or even better platform-dev. I can see a message from you on eclipse-dev: https://www.eclipse.org/lists/eclipse-dev/msg11420.html. I also verified that the moderator queue is empty.

Dani



From:        Ari Kast <[hidden email]>
To:        "Eclipse JDT general developers list." <[hidden email]>
Date:        22.06.2020 05:35
Subject:        [EXTERNAL] Re: [jdt-dev] how to create new junit test
Sent by:        [hidden email]




Thanks Lars and Mickael,

I submitted a bug for the behavior I'm investigating here https://bugs.eclipse.org/bugs/show_bug.cgi?id=564448

My thought was to change the "layouts" field to some kind of circular buffer or something that's more agnostic about the direction in which it grows -- or maybe even just a simple hashmap with a bit of decoration to prevent it from growing larger than CACHE_SIZE, and an eviction policy that calls dispose() when something gets replaced.  One way or another I'd like to find a way to keep that cache full, which I assume would yield benefits beyond just this one bug (for example currently typing one letter into a 200-tall block selection takes abt 45 seconds on my machine, so I'd like to see what impact this has on that and then investigate that further assuming it's still slow after this fix).

Is it preferable to write my own cache utility as opposed to using 3rd party libs?

BTW I tried first sending this reply to the suggested eclipse-dev mailing list but I think that message has been awaiting moderator approval for several days now. 

Thanks for any tips/suggestions/guidance.

Ari


On Thu, Jun 18, 2020 at 3:53 PM Mickael Istria <[hidden email]> wrote:
Hi,

On Thu, Jun 18, 2020 at 9:26 PM Ari Kast <[hidden email]> wrote:
I'm doing some work inside org.eclipse.swt.custom.StyledTextRenderer to improve the cache hit ratio for the "layouts" field, and I wanted to write test cases for my work.

Did you open a bug on bugs.eclipse.orgabout this work? It would improve collaboration opportunities.

To my surprise though, at the top of the test class when I import org.eclipse.swt.custom.StyledTextRenderer, some Eclipse rule seems to kick in and immediately delete my import statement.

If this StyledTextRenderer type isn't used anywhere in the code, the import is just cleaned up.
Also, the StyledTextRenderer is "package" visible only, so it's not really possible to interact with it from the tests bundle.. So please open a bug with more details about what you're trying to achieve and we'll discuss there what's doable.

Cheers,

_______________________________________________
jdt-dev mailing list

[hidden email]
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jdt-dev_______________________________________________
jdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jdt-dev


_______________________________________________
jdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev

_______________________________________________
jdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev