testing methods with junit

[Argoni Mahun]

hi, I wrote junit tests for a class which has add and delete method. For add method I instantiated the class call add and then asserted. For delete method I first called add method, then deleted it and asserted. I wonder if it is true to call add method while testing delete method. because add can be wrong and effect the delete method test case. İs there any better practice?

My code is:

public void testAddLMTask() {
LMTask task = new LMTask();
LMTaskCtrl taskCtrl = new LMTaskCtrl();
taskCtrl.addTask(task);
assertEquals("Task not added", 1, taskCtrl.getTaskList().size());
}

public void testDeleteTask() {
LMTask task = new LMTask();
LMTaskCtrl taskCtrl = new LMTaskCtrl();
taskCtrl.addTask(task);
taskCtrl.deleteTask(task);
assertEquals("Task not deleted", 0, taskCtrl.getTaskList().size());
}

[Jeanne Boyarsky]

I see no problem with calling add. You have another test that shows it is working. If add becomes a blank method, that first test fails.

[Brian Burress]

I agree with Jeanne's assessment. Specifically, I have seem some approaches where the codeer avoids assertion errors that cascade through the tests (i.e. if one function point fails, you'd want to avoid it causing a bunch of other tests to fail). You could split the code up conceptually into sections using comments like "setup" and "actual test". In the testDeleteTask, the addTask logic would be under setup and as such one would not expect to see asserts in the section.

With that said, there are some tests where I do have asserts to validate state before and after a test. Arguably when I do this I am effectively merging multiple tests into one. When I do this, I am typically writing an integration or acceptance type of test. It appears your test is more of a unit test the approach as you have coded "fits" ok.