junit.framework.Assert vs. org.junit.Assert

I think we need some documentation to show the differences between these two. I just tried http://stackoverflow.com/questions/1092219/assertcontains-on-strings-in-junit and was confounded for 15 minutes that it didn’t work, until I noticed how wonky wonka can be:

import static org.junit.Assert;
import static junit.framework.Assert.*;
import static org.hamcrest.Matchers.*;
import org.junit.Test;


public class WonkyTest {

    @Test
    public void testAssertThatWat() {
        String foo = "bar";
        assertThat(foo, containsString("ba"));
    }
}

Notice that I only included the Assert class from org.junit, but statically imported junit.framework.Assert. IDEs and other code completion tools sometimes do this, and the differences between the two are unclear.

This is really confusing. What framework is and why it’s necessary should be documented, and if it’s not something end users should use maybe it should be encapsulated. If it’s an interface piece for other frameworks (like JBehave and Grails jumping on top of JUnit), that should probably be a separate module that depends on junit-core.

I think this really presses forward the need to Mavenize this project. I see that was done recently, but we need to think POM structure and modules now.

For a wild stab, something like junit-core should have the standard junit functionality, junit-extend should have things that include hamcrest, junit-experimental could have experimental additions (I’ve never used a theory, would be nice to keep the src out of my dependency chain unless I’m explicitly using it).

[dsaff]

The main thing we need to do is to tell people “in new code, only use org.junit.Assert”. junit.framework.Assert is only there to support legacy tests.

[dsaff]

@leadVisionary , I think that @kcooney 's comments are important and valid. We can try starting with his suggestion, and then see whether there’s further pain caused by the JUnit 3 classes.