esting this class would be reduced by 0%.
Cost: 3,431

Class org.kiy0taka.dbunit.DataSetBuilder.RTrimTable is hard to test because:

It is expensive to construct an instance of the class, and every test will need to call a constructor.

These static initializers will need to be run once, when the class is loaded. Why is it bad?

On line 155, static Pattern compile(String) is declared contributing 33% of total class cost

Instead of initializing this state statically, try initializing a fresh copy in each instance. Creating new objects in Java is cheap, and this static state can't be cleaned up between tests.

Cost: 2,641

Class org.kiy0taka.dbunit.DbUnitRunner.DataSetType.2 is hard to test because:

These collaborators cannot be mocked, so it is impossible to unit test this class in isolation.

Non-mockable collaborators: Why is it bad?

On line 89, XlsDataSet(InputStream) is called contributing 100% of total class cost

This method call can't be mocked out from a unit test because the test cannot control how the object is instantiated. This can be caused by: - the object was created using new, - it was returned by a non-mockable collaborator, or - the method is declared final or private, which prevents overriding in a subclass

Cost: 2,606

Class org.kiy0taka.dbunit.DbUnitRunner.DbUnitStatement is hard to test because:

These collaborators cannot be mocked, so it is impossible to unit test this class in isolation.

Non-mockable collaborators: Why is it bad?

On line 252, URL getResource(String) is called contributing 28% of total class cost
On line 203, IDataSet toDataSet() is called contributing 21% of total class cost
On line 228, IDataSet toDataSet() is called contributing 20% of total class cost
On line 268, void setPropertiesByString(Properties) is called contributing 20% of total class cost
On line 266, DatabaseDataSourceConnection(DataSource, String) is called contributing 3% of total class cost

This method call can't be mocked out from a unit test because the test cannot control how the object is instantiated. This can be caused by: - the object was created using new, - it was returned by a non-mockable collaborator, or - the method is declared final or private, which prevents overriding in a subclass

Static methods are called: Why is it bad?

On line 237, static method void assertEquals(IDataSet, IDataSet) is called contributing 3% of total class cost
On line 203, static method DataSetBuilder dataSet(IDataSet) is called contributing 2% of total class cost
On line 228, static method DataSetBuilder dataSet(IDataSet) is called contributing 2% of total class cost

Since these static methods are complex, we want to mock them out in the unit test. If they are declared in your code, refactor the methods to be non-static, and inject an instance of the class. Otherwise, you can create a wrapper object.

The code itself is complex, and it will be hard to test all the different paths of execution

There are complicated methods Why is it bad?

Around line 266, method IDatabaseConnection createDatabaseConnection() has high complexity contributing 3% of total class cost

Refactor the method by breaking the complex portions into several smaller methods.

Cost: 1,052

Class org.kiy0taka.dbunit.DbUnitRunner.DataSetType.1 is hard to test because:

These collaborators cannot be mocked, so it is impossible to unit test this class in isolation.

Non-mockable collaborators: Why is it bad?

On line 84, FlatXmlProducer(InputSource) is called contributing 100% of total class cost

This method call can't be mocked out from a unit test because the test cannot control how the object is instantiated. This can be caused by: - the object was created using new, - it was returned by a non-mockable collaborator, or - the method is declared final or private, which prevents overriding in a subclass

Cost: 833

Class org.kiy0taka.dbunit.DataSetBuilder is hard to test because:

It is expensive to construct an instance of the class, and every test will need to call a constructor.

Constructors with a high cyclomatic complexity Why is it bad?

On line 54, DataSetBuilder(IDataSet) is complex contributing 6% of total class cost
On line 54, DataSetBuilder(IDataSet) is complex contributing 6% of total class cost
On line 54, DataSetBuilder(IDataSet) is complex contributing 6% of total class cost
On line 54, DataSetBuilder(IDataSet) is complex contributing 6% of total class cost
On line 54, DataSetBuilder(IDataSet) is complex contributing 6% of total class cost

Don't perform work in the constructor. Instead, initialize all the needed state, and pass it as a new parameter.

You are calling new in the constructor Why is it bad?

On line 42, new instance of HashMap() created contributing 6% of total class cost

Using new couples this class to the one instantiated, preventing you from testing this class in isolation of that collaborator. Instead, pass an instance of the collaborator as a new constructor parameter.

These collaborators cannot be mocked, so it is impossible to unit test this class in isolation.

Non-mockable collaborators: Why is it bad?

On line 150, DataSetBuilder(IDataSet) is called contributing 6% of total class cost

This method call can't be mocked out from a unit test because the test cannot control how the object is instantiated. This can be caused by: - the object was created using new, - it was returned by a non-mockable collaborator, or - the method is declared final or private, which prevents overriding in a subclass

Static methods are called: Why is it bad?

On line 129, static method ITable excludedColumnsTable(ITable, String[]) is called contributing 55% of total class cost

Since these static methods are complex, we want to mock them out in the unit test. If they are declared in your code, refactor the methods to be non-static, and inject an instance of the class. Otherwise, you can create a wrapper object.

The code itself is complex, and it will be hard to test all the different paths of execution

There are complicated methods Why is it bad?

Around line 117, method IDataSet toDataSet() has high complexity contributing 7% of total class cost
Around line 84, method DataSetBuilder excludeColumns(String[]) has high complexity contributing 6% of total class cost

Refactor the method by breaking the complex portions into several smaller methods.

Cost: 405

Class org.kiy0taka.dbunit.DbUnitTest.Operation is hard to test because:

These collaborators cannot be mocked, so it is impossible to unit test this class in isolation.

Static methods are called: Why is it bad?

On line 82, static method Enum valueOf(Class, String) is called contributing 100% of total class cost

Since these static methods are complex, we want to mock them out in the unit test. If they are declared in your code, refactor the methods to be non-static, and inject an instance of the class. Otherwise, you can create a wrapper object.

Cost: 337

Class org.kiy0taka.dbunit.DbUnitTest.Sort is hard to test because:

These collaborators cannot be mocked, so it is impossible to unit test this class in isolation.

Static methods are called: Why is it bad?

On line 144, static method Enum valueOf(Class, String) is called contributing 100% of total class cost

Since these static methods are complex, we want to mock them out in the unit test. If they are declared in your code, refactor the methods to be non-static, and inject an instance of the class. Otherwise, you can create a wrapper object.

Cost: 337

Class org.kiy0taka.dbunit.DbUnitRunner.DataSetType is hard to test because:

These collaborators cannot be mocked, so it is impossible to unit test this class in isolation.

Static methods are called: Why is it bad?

On line 81, static method Enum valueOf(Class, String) is called contributing 100% of total class cost

Since these static methods are complex, we want to mock them out in the unit test. If they are declared in your code, refactor the methods to be non-static, and inject an instance of the class. Otherwise, you can create a wrapper object.

http://testabilityexplorer.org