4

I'm working a program which is parsing some files and than process these files. The parser is well tested, but I have to test the processing part too. The problem is to unit test functions I need big objects which comes from the parser. I don't want to create manually objects(it's too much time). My goal is to refactor some process functions because some function do a lot of thing and working with huge objects.

The language is java, and I use JUnit.

I tried to save objects and load in the unit test, but this is the only way? Any suggestions?

Thanks in advance, Peter

Péter Török
  • 114,404
  • 31
  • 268
  • 329
hcpeter
  • 614
  • 3
  • 11
  • 24
  • 1
    Sounds to me like you're on the right track - cut the functions into smaller ones, that handle smaller data structures. – S.L. Barth is on codidact.com Sep 08 '11 at 08:23
  • Could you explain what do you mean by saving and loading object in the unit test? – bbaja42 Sep 08 '11 at 08:23
  • When running the process methods I save the objects which are filled with the parsed data. (I use ObjectOutputStream) In the test load this object and passing to the function argument. – hcpeter Sep 08 '11 at 08:28

4 Answers4

1

You may try to mock the parsed objects, defining only the needed return values for specific methods called by the processing code. This is useful if the object creation is complex and/or the object has many external dependencies.

The other options are what you listed: load the parsed objects from files directly, or create them by hand in your unit tests. I usually prefer the latter option, because unit tests should be self- containing as much as possible. Note that the manual creation may be tedious, but you need to write that code only once, then you can reuse it with different parameters for all of your unit tests. While with the file based approach, you need to create loads of files which probably differ in various small bits, and they quickly become a maintenance headache. E.g. what if the file format changes in the next release? You need to manually edit all test files. While with first approach, you only need to modify the test setup code in one place.

Péter Török
  • 114,404
  • 31
  • 268
  • 329
  • Thank you, I'll do the manual way. So creating objects by hand and fill it test data. It may be tricky, but the maintenance could be difficult if I save and load objects. And I also check a mocking framework (-: – hcpeter Sep 08 '11 at 18:47
1

When you say "big objects", do you mean that they are assembled from objects of many classes?

That suggests to me that you need to simplify the API used for creating these objects. You could try using the Builder design pattern. The Builder design pattern is useful when you need to do many things to create an object. Instead of the parser creating "big objects", have it delegate to a Concrete Builder object, which creates the objects for it. You could test the parser using a Test Spy Builder. Your unit tests of the "processor" part could use the same Concrete Builder to simplify (abstract) creation of the objects. If it is still too complicated, consider using the Facade design pattern: layer another API on top of the Concrete Builder to simplify creation of the objects.

When you say "big objects",do you mean that they occupy much memory?

That suggests you unit-testing approach is wrong. Try an incremental approach where you start with the very simple and small cases.

Community
  • 1
  • 1
Raedwald
  • 46,613
  • 43
  • 151
  • 237
0

It is hard to advise you without further details and knowing the nature of your code, but you should have a read of test doubles sections in xUnit patterns book to see what is most suited to you.

Ashkan Aryan
  • 3,504
  • 4
  • 30
  • 44
0

Two viable options:

  1. use the API used by the parser to create one or more sets of objects to perform processing tests on
  2. write some simple test code that generates temporary files, or in-memory buffers, in the format read by the parser

If the second options seems preferable, you presumably have a bad, or unstable, API. But sometimes that being a true statement doesn't mean it's going to become a false one any time soon.

soru
  • 5,464
  • 26
  • 30