It depends on what you are trying to test. Cassandra Maven Plugin (of which I was one of the original authors) and Cassandra Unit both do something very similar in that they start an in-JVM instance of Cassandra.
This works great if you just want to do some CRUD stuff in you integration tests, but really does not help if you want to test scenarios like consistency level failures and retries in the face of various failure cases, particularly for multiple datacenters. And Cassandra is just a beast at this point so it means you need a lot of memory for you tests to run.
To really verify things like the above, I recommend using Simulacron:
https://github.com/datastax/simulacron/blob/master/doc/java_api/README.md
And an example integration:
https://github.com/datastax/java-driver/blob/9f0d89799a8a1e4cd1022dd7c43333924c36a648/integration-tests/src/test/java/com/datastax/oss/driver/api/core/ProtocolVersionMixedClusterIT.java
This is what the driver teams use to test behavior scenarios, though they still rely on a CCM test bridge (also an option) for a lot of block and tackle stuff. For both, the way it's plumbed into maven in that project should be used as an example of best practices:
https://github.com/datastax/java-driver/blob/3.x/pom.xml#L749-L816
And profile switching for such:
https://github.com/datastax/java-driver/blob/3.x/pom.xml#L925-L947
And using the profiles:
https://github.com/datastax/java-driver/blob/3.x/driver-core/src/test/java/com/datastax/driver/core/PreparedStatementTest.java#L146
To really get your head around it, I recommend pulling down the driver project and picking it apart to see how this is all put together. Probably the biggest win is that this whole project does not have any dependency on Cassandra code.