0

Unit tests have become increasingly important in modern software development, and I'm finding myself lost in the dust. Primarily a Java programmer, I understand the basics of unit tests: have methods in place that test fundamental operations in your application. I can implement this for the simple (and often used as examples) cases:

public boolean addNumbers(int a, intb) {return a + b;}
//Unit test for above
public boolean testAddNumbers() {return addNumbers(5, 10) == 15;}

What confuses me is how to move this out into practical application. After all, most simple functions are already in APIs or the JDK. A real world situation that I do frequently in my job is data access, i.e. writing DAOs to work with a database. I can't write static tests like the example above, because pulling a record set from an Oracle box can return a whole manner of things. Writing a generalized unit test that just looks for a particular pattern in the return set seems too broad and unhelpful. Instead, I write no unit tests. This is bad.

Another example of a case where I don't know how to approach writing tests is web applications. My web applications are typically built on a J2EE stack, but they don't involve much logic. Generally it's delivering information from databases with little to no manipulation. Are these inappropriate targets for unit tests?

In short, I've found the vast majority of unit test examples to focus on test cases that are too simplistic and not relevant to what I do. I'm looking for any (preferably Java) examples/tips on writing unit tests for applications that move and display data, not perform logic on it.

WannabeCoder
  • 498
  • 1
  • 5
  • 20
  • 1
    I'm voting to close this question as off-topic because it belongs on http://programmers.stackexchange.com – Andy Brown Feb 01 '15 at 17:50
  • possible duplicate of [How to unit test this particular scenario](http://stackoverflow.com/questions/20859777/how-to-unit-test-this-particular-scenario) – BartoszKP Feb 01 '15 at 17:50
  • To explain the reason for my vote: you may well get better answers to this on http://programmers.stackexchange.com which is better suited to conceptual questions about development methodologies, qa and testing (see: http://programmers.stackexchange.com/help/on-topic) – Andy Brown Feb 01 '15 at 17:51
  • I wavered on whether or not to post it there instead, but since I was looking for a Java-specific answer (preferably), I decided to go with here. – WannabeCoder Feb 01 '15 at 18:01

1 Answers1

2

You generally don't write unit tests for DAOs, but integration tests. These tests basically consist in

  • setting the database in a well-known state, suitable for the test
  • call the DAO method
  • verify that the DAO returns the right data and/or changes the stateof the database as expected.

Shameless plug: DbSetup is good tool to do the first part. But other tools exist like DBUnit.

To test the business logic of the app (complex or not, that doesn't change much), you typically mock the DAOs using a mocking framework like Mockito:

SomeDao mockDao = mock(SomeDao.class);
when(mockDao.findAllEmployees()).thenReturn(Arrays.asList(e1, e2, e3));
SomeService service = new SomeService(mockDao);
someService.increaseSalaryOfAllEmployeees(1000);
// todo verify that e1, e2 and e3's salary is 1000 larger than before
JB Nizet
  • 678,734
  • 91
  • 1,224
  • 1,255
  • Ah, that's a shame. I'm more-or-less spearheading the attempt to bring modern programming practices to my team at work, and having to work with something more complicated than jUnit will not help my efforts. (Yes, I know how terrible that is.) – WannabeCoder Feb 01 '15 at 17:58
  • JUnit is perfectly able to execute such tests, despite its name. Java code is Java code. Whether the Java code does an addition or accesses a database doesn't change anything. I use JUnit, and most people do (or use TestNG), to write such tests. By "integration" test, what is meant is that the tests don't just involve a single unit of code, but also the database that is used by this code. – JB Nizet Feb 01 '15 at 18:01