0

I have two classes, Parser and Item. The Parser class parses some structured document and returns Item-objects if you call something like Parser::GetItem(int some_id). The Item class was written with the "Tell - don't ask" principle in mind. By that I mean it doesn't have getter-methods for several internal variables which were filled by the Parser on construction.

The question now is: How can I unittest the Parser class? How to check if the internal Item variables were correctly parsed? Do I have to rearrange my classes? Is it maybe bad design that the parser-interface returns fully constructed Item objects?

lslah
  • 556
  • 8
  • 17

1 Answers1

1

Your design might not be ideal, but it's difficult to know without looking at the code.

Something to ask yourself is the Parser hiding too much information, and as a consequence doing too much.

I strongly suggest you to watch this presentation from Michael Feather, in which (interestingly) he discusses how to improve the design of a parser using tests, and it looks like the problem he solves is similar to what you're trying to solve. Michael Feathers - the deep synergy between testability and good design

Augusto
  • 28,839
  • 5
  • 58
  • 88
  • Now I've splitted the parser into two classes. The actual parser, which stores just strings in structs and a item builder class. The later fetches the needed structures from the parser and does all the conversion and checking stuff like translating strings into numbers.. Now I can at least check if the parser extracts the correct information from the document. But the problem remains because I'm not able to check if all conversions in the item builder work properly. I think I should minimize the functionality of the item builder and swap out as much as possible to testable helper classes. – lslah Jul 11 '13 at 12:12
  • Thanks for your answer! I think you hit the crucial point that my parser was too big. And also thanks for the link. I'll watch it later. – lslah Jul 11 '13 at 12:15