The page I am working on has a javascript function executed to print parts of the page. For some reason, printing in Safari, causes the window to somehow update. I say somehow, because it does not really refresh as in reload the page, but rather it starts the "rendering" of the page from start, i.e. scroll to top, flash animations start from 0, and so forth. The effect is reproduced by this fiddle: http://jsfiddle.net/fYmnB/ Clicking the print button and finishing or cancelling a print in Safari causes the screen to "go white" for a sec, which in my real website manifests itself as something "like" a reload. While running print button with, let's say, Firefox, just opens and closes the print dialogue without affecting the fiddle page in any way. Is there something with my way of calling the browsers print method that causes this, or how can it be explained - and preferably, avoided? P.S.: On my real site the same occurs with Chrome. In the ex
The old method (of Junit 3) was to mark the test-classes by extending junit.framework.TestCase. That inherited junit.framework.Assert itself and your test-class gained the ability to call the assert-methods this way.
ReplyDeleteSince version 4 of junit the framework uses Annotations for marking tests. So you no longer need to extend TestCase. But that means, the assert-methods aren't available. But you can make a static import of the new Assert-class. That's why all the assert-methods in the new class are static methods. So you can import it this way:
import static org.junit.Assert.*;
After this static import, you can use this methods without prefix.
At the redesign they also moved to the new package org.junit, that follows better the normal conventions for package-naming.
JUnit 3.X: junit.framework.Assert
ReplyDeleteJUnit 4.X: org.junit.Assert
Prefer the newest one, especially when running JDK5 and higher with annotation support.
I believe they are refactoring from junit.framework to org.junit and junit.framework.Assert is maintained for backwards compatibility.
ReplyDeleteThere is in fact a functional change: org.junit.Assert will complain if you use the two-argument assertEquals() with float or double, while junit.framework.Assert will silently autobox it.
ReplyDeleteI did a rough source code compare and there are no serious changes.
ReplyDeleteLot of comments were added in org.junit.Assert and some refactorings are done.
The only change is the comparison with Arrays. There are some code clean ups, but there's (imho) no functional change.
There are other functional change today.
ReplyDeleteorg.junit.Assert.assertEquals(float expected, float actual, float delta) is exist no longer.
It still exists in junit.framework.
Not easy to compare floats in these conditions... I must cast them in object and then use assertEquals(Object expected, Object actual).
Anyone has a more fluent solution (without reusing the old api, of course) ?