Ant is like make which is used to automate the task of
building the applications.
Ant, similar to make can be used to do any task other
than building application.
In makefiles we use commands to carry out tasks.
In ant we use Ant Taska which are nothing but java
classes to carry out a taks.
Note: we can also run commands using exec task.
Make uses make files. ant uses xml build files.
In ant's build file we can define the targets. A taget defines howto carry out things like compiling, removing, creating direct.
What are the advantages to use an ANT?
- Build IN Java, USING Java, and FOR Java
- XML Build File is Easier to Build, Read, and Maintain than MAKE fileEasier to Extend
- Supports Java Tools (javac, javadoc, etc.)
- Ant is much faster than using MAKE ? Each command is a new processAnt runs within the JVM
- Each command is executed from within JVM
- Tools like javac are new threads – not new process
- Compiling large number of java source files is MUCH,MUCH faster with Ant
- Ant's Debug Options are very helpful
JUnit:
Simple Test Case
How do you write testing code?
The simplest way is as an expression in a debugger. You can change debug expressions without recompiling, and you can wait to decide what to write until you have seen the running objects. You can also write test expressions as statements which print to the standard output stream. Both styles of tests are limited because they require human judgment to analyze their results. Also, they don't compose nicely- you can only execute one debug expression at a time and a program with too many print statements causes the dreaded "Scroll Blindness".
JUnit tests do not require human judgment to interpret, and it is easy to run many of them at the same time. When you need to test something, here is what you do:
Annotate a method with @org.junit.Test
When you want to check a value, import org.junit.Assert.* statically, call assertTrue() and pass a boolean that is true if the test succeedsFor example, to test that the sum of two Moneys with the same currency contains a value which is the sum of the values of the two Moneys, write:
@Test public void simpleAdd() {
Money m12CHF= new Money(12, "CHF");
Money m14CHF= new Money(14, "CHF");
Money expected= new Money(26, "CHF");
Money result= m12CHF.add(m14CHF);
assertTrue(expected.equals(result));
}If you want to write a test similar to one you have already written, write a Fixture instead.
Fixture
What if you have two or more tests that operate on the same or similar sets of objects?
Tests need to run against the background of a known set of objects. This set of objects is called a test fixture. When you are writing tests you will often find that you spend more time writing the code to set up the fixture than you do in actually testing values.
To some extent, you can make writing the fixture code easier by paying careful attention to the constructors you write. However, a much bigger savings comes from sharing fixture code. Often, you will be able to use the same fixture for several different tests.
Each case will send slightly different messages or parameters to the fixture and will check for different results.
When you have a common fixture, here is what you do:
Add a field for each part of the fixture
Annotate a method with @org.junit.Before and initialize the variables in that method
Annotate a method with @org.junit.After to release any permanent resources you allocated in setUpFor example, to write several test cases that want to work with different combinations of 12 Swiss Francs, 14 Swiss Francs, and 28 US Dollars, first create a fixture: public class MoneyTest {
private Money f12CHF;
private Money f14CHF;
private Money f28USD;
@Before public void setUp() {
f12CHF= new Money(12, "CHF");
f14CHF= new Money(14, "CHF");
f28USD= new Money(28, "USD");
}
}Once you have the Fixture in place, you can write as many Test Cases as you'd like. Add as many test methods (annotated with @Test) as you'd like.
Running Tests
How do you run your tests and collect their results?
Once you have tests, you'll want to run them. JUnit provides tools to define the suite to be run and to display its results.
To run tests and see the results on the console, run:
org.junit.runner.JUnitCore.runClasses(TestClass1.class, ...);
You make your JUnit 4 test classes accessible to a TestRunner designed to work with earlier versions of JUnit, declare a static method suite that returns a test.
public static junit.framework.Test suite() {
return new JUnit4TestAdapter(Example.class);
}
Expected ExceptionsHow do you verify that code throws exceptions as expected?
Verifying that code completes normally is only part of programming.
Making sure the code behaves as expected in exceptional situations is part of the craft of programming too. For example:
new ArrayList
If we wanted to verify that ArrayList throws the correct exception, we would write:
@Test(expected= IndexOutOfBoundsException.class) public void empty() {
new ArrayList
- Assertions for testing expected results
- Test fixtures for sharing common test data
- Test runners for running tests
- JUnit was originally written by Erich Gamma and Kent Beck.
How do I install JUnit?
First, download the latest version of JUnit, referred to below as junit.zip.
Then install JUnit on your platform of choice:
Windows
To install JUnit on Windows, follow these steps:
- Unzip the junit.zip distribution file to a directory referred to as %JUNIT_HOME%.
- Add JUnit to the classpath:
set CLASSPATH=%CLASSPATH%;%JUNIT_HOME%\junit.jar
Unix (bash):
To install JUnit on Unix, follow these steps:
1.Unzip the junit.zip distribution file to a directory referred to as $JUNIT_HOME.
2.Add JUnit to the classpath:
export CLASSPATH=$CLASSPATH:$JUNIT_HOME/junit.jar
(Optional) Unzip the $JUNIT_HOME/src.jar file.
Test the installation by running the sample tests distributed with JUnit.
Note that the sample tests are located in the installation directory directly, not the junit.jar file. Therefore, make sure that the JUnit installation directory is on your CLASSPATH. Then simply type:
java org.junit.runner.JUnitCore org.junit.tests.
All the tests should pass with an "OK" message.
If the tests don't pass, verify that junit.jar is in the CLASSPATH.
Finally, read the documentation.
How do I write a test that fails when an unexpected exception is thrown?
Declare the exception in the throws clause of the test method and don't catch the exception within the test method. Uncaught exceptions will cause the test to fail with an error.
The following is an example test that fails when the IndexOutOfBoundsException is raised:
@Test
public void testIndexOutOfBoundsExceptionNotRaised()
throws IndexOutOfBoundsException {
ArrayList emptyList = new ArrayList();
Object o = emptyList.get(0);
}
In Java 1.4, assert is a keyword. Won't this conflict with JUnit's assert() method?
JUnit 3.7 deprecated assert() and replaced it with assertTrue(), which works exactly the same way.
JUnit 4 is compatible with the assert keyword. If you run with the -ea JVM switch, assertions that fail will be reported by JUnit.
How do I test things that must be run in a J2EE container (e.g. servlets, EJBs)?
Refactoring J2EE components to delegate functionality to other objects that don't have to be run in a J2EE container will improve the design and testability of the software.
cactus is an open source JUnit extension that can be used to test J2EE components in their natural environment.
Why not just use System.out.println()?
Inserting debug statements into code is a low-tech method for debugging it. It usually requires that output be scanned manually every time the program is run to ensure that the code is doing what's expected.
It generally takes less time in the long run to codify expectations in the form of an automated JUnit test that retains its value over time. If it's difficult to write a test to assert expectations, the tests may be telling you that shorter and more cohesive methods would improve your design.
Why not just use a debugger?
Debuggers are commonly used to step through code and inspect that the variables along the way contain the expected values. But stepping through a program in a debugger is a manual process that requires tedious visual inspections. In essence, the debugging session is nothing more than a manual check of expected vs. actual results.
Moreover, every time the program changes we must manually step back through the program in the debugger to ensure that nothing broke.
It generally takes less time to codify expectations in the form of an automated JUnit test that retains its value over time. If it's difficult to write a test to assert expected values, the tests may be telling you that shorter and more cohesive methods would improve your design.
How do I launch a debugger when a test fails?
Start the TestRunner under the debugger and configure the debugger so that it catches the junit.framework.AssertionFailedError.
How you configure this depends on the debugger you prefer to use. Most Java debuggers provide support to stop the program when a specific exception is raised.
Notice that this will only launch the debugger when an expected failure occurs.
1 comment:
Hi
Tks very much for post:
I like it and hope that you continue posting.
Let me show other source that may be good for community.
Source: Sample interview questions
Best rgs
David
Post a Comment