Alexis described the difference between unit and integration tests completely above, but I felt the need to chime in on the particularities of java and how to write and notice the difference between unit and integration tests.
Unit Tests
Generally for unit tests, a mocking framework is used to mock certain dependencies of a particular class and of a particular method. Since with unit tests, we only want to test a single unit of the code (class methods) we don't want to have to worry about the other classes that method communicates with, so we mock those external dependencies and often verify that the method call to those external dependencies was carried out, without actually running the external method.
Mocking is a powerful tool to write strong tests for your application and it encourages developers to write clean, well-designed and loosely-coupled code.
A common example you will see throughout a java project is the Mockito Framework. I advise reading more on the topic here.
Integration Tests
"Testing performed to expose defects in the interfaces and in the interactions between integrated components or systems."
In java terms, this often refers to the interaction between classes. How class A calls class B and ensuring the link between them works correctly in regard to data transmission, error handling and control flow. Integration tests don't typically use a mocking framework but in-practice they can. Generally you want to fully test the component interactions without mocking out the dependency link. However, this depends on your needs in regard to application design. More information on this can be found here
Typically with integration tests, the database is tested regarding the CRUD (Create-Read-Update-Delete) operations to it. Unit tests have no connection to a database. This is because tests requiring a database connection will have side effects by their very nature. There is leakage from the concept of testing a "single unit" of your code. Therefore, normally the database is tested from integration tests and up.
Requiring this database connection will often cause your integration tests to run dramatically slower than your unit tests. This is due to needing to roll up the database for each set of transactions for a test class and often if you're using an IOC container (like Spring) then further overhead to time will exist. Typically, for integration tests we use a test database, rather than the real database, and is often in-memory.
In summary
If your project is designed well, the unit tests and integration tests should be segregated by package. It makes sense conceptually, and architecturally it is a better approach for developers to adapt to and feel comfortable with. It also completely draws that line between what is an integration test and what is a unit test.
Unit tests are very fast and should be the foundation of your application test suite.
Integration tests can be slow in most cases due to requiring a database connection but can cover more variants than a unit test can.
Unit tests typically use a mocking framework to mock external dependencies.
Integration tests typically use the real dependency objects for testing.
Unit tests should not have a database connection.
Integration tests typically do have a connection to a test database.
