This Confluence has been LDAP enabled, if you are an ASF Committer, please use your LDAP Credentials to login. Any problems file an INFRA jira ticket please.
Author: Alex Huang
The following is a FAQ on how to do write unit tests in cloud stack.
Within each source directory, there's also a test directory that contains the tests for that jar file. For example, utils/src and utils/test. If you have files other than source files, they should go into "test/resource" directory.
A suite of tests is a set of tests that are run together. Take a look at DbUpgrade22Test.java
. Junit has annotations you can use for that.
To run the entire unittest suite:ant unittestTo run just one test that you wroteant test -Dtest=filename without path and without ".java"You can also run the unit tests individually from eclipse. Kelven can update this space on how to do this.
All outputs are confined to "unittest" directory under the directory where you are running.
All logging in the source code being tested go into the unittest/TEST* files. All logs are embedded inside. If you want to change that, you can modify utils/test/resource/log4j.xml. Currently, there's no separate file appender there. Everything goes to console which gets captured by junit and put into its output file.
Transaction.getStandaloneConnection(). This returns a raw DB connection so you're responsible for closing out any resources, including ResultSet, Connection, PreparedStatements, etc.Connection conn = Transaction.getStandaloneConnection();
PreparedStatement pstmt = conn.prepareStatement("SELECT 1");
ResultSet rs = pstmt.executeQuery();
assert (rs.next() && rs.getInt(1) == 1) : "How come I'm not getting back 1?";
For example, assuming you have a script file in "server/test/resource/VerionDaoImplTest/2.1.7/2.1.7.sample.sql", you will write the following. Note that "server" is missing in the path.DbTestUtils.executeScript("test/resource/PreviousDatabaseSchema/2.1.7/2.1.7.sample.sql");
ComponentLocator has a static method to inject classes. For example, if you're testing VersionDaoImpl, you can do the following.VersionDao dao = ComponentLocator.inject(VersionDaoImpl.class);
There is a MockComponentLocator that allows you go add all of the components you needed. For example, if you need to test a FirstFitPlanner which has the following components injected.
@Inject private HostDao _hostDao;
@Inject private CapacityDao _capacityDao;
@Inject private DataCenterDao _dcDao;
@Inject private HostPodDao _podDao;
@Inject private ClusterDao _clusterDao;
@Inject DetailsDao _hostDetailsDao = null;
@Inject GuestOSDao _guestOSDao = null;
@Inject GuestOSCategoryDao _guestOSCategoryDao = null;
@Inject CapacityManager _capacityMgr;
@Inject ConfigurationDao _configDao;MockComponentLocator locator = new MockComponentLocator("management-server");
FirstFitPlanner planner = ComponentLocator.inject(FirstFitPlanner.class);
...testing code...Note that by doing this, you have complete control of the components that you are injecting. For example, let's say you thought CapacityManagerImpl is too complicated and, instead, you want to inject a mocked up CapacityManager that supplies the values you want to test. You can do "locator.addManager(MockCapacityManagerImpl.class)" instead. You'll have to write a MockCapacityManagerImpl class file of course.
No. Unit testing is for specific testing to force issues to come up early. If you need to entire components.xml or components-premium.xml for your tests, what you really need is to start a server and have a predefined set of testcases run as the web client. That's not part of the unit testing. We need to develop other means to do that. Once completed, we'll make this known on this page.
You can but largely there's no reason. components-premium.xml or components.xml is a way to integrate our code together with different components and therefore the files can change quickly. Most of the time when you run unit tests, you want to specify exactly which components are necessary to test the component your testing. Sometimes, you might want even want to mock up certain components so using components.xml is not useful. MockComponentLocator gives you the best way to do this by allowing you to construct the environment before running your own test. The same goes for log4j-cloud.xml. Why rely on a log configuration for production environment when you can specify your own for unit tests?