0

I have a class which can only be initialised using builder pattern i.e. it doesn't have any other constructor. Now I am Unit-Testing this class.

My question is that since builder class is totally a different class (My Builder class is outside the class it is building), Is it a good practice to trust the object which builder is returning? Because maybe there is something I have missed in builder since I have not tested the builder class.

Or should I first test the builder class, be thorough with it and then test the other class. Or should I create a constructor in my class with parameters just for testing.

I am not sure what is the correct approach to do this.

Sneh
  • 3,527
  • 2
  • 19
  • 37
  • Check this out [Link](https://www.kenneth-truyers.net/2013/07/15/flexible-and-expressive-unit-tests-with-the-builder-pattern/). This is using Builder Pattern to simplify the test cases. Hope this will clear some air. – YoungHobbit Oct 16 '15 at 23:49
  • Yeah, I am doing the same atm but what I am wondering is what if my builder is broken? It's like I am dependent on builder to return me the correct result. I feel it's not a good approach. – Sneh Oct 16 '15 at 23:51
  • Don't test classes, test units of functionality. If this builder is so intricately tied up with the target class, treat them as a single unit. – chrylis -cautiouslyoptimistic- Oct 17 '15 at 00:04
  • @chrylis Actually yeah that is a better idea, test the builder with the class I am trying to build. And yep I am testing for functionality only. Used incorrect wordings in the question. – Sneh Oct 17 '15 at 00:06
  • What is wrong with mocking the builder? – GhostCat Oct 17 '15 at 00:25
  • If I mock builder how will I create the object @Jägermeister – Sneh Oct 17 '15 at 00:28
  • By having the mocked builder return those values that you want to be returned. That is what mocks are there for - to allow you to exactly control the input that goes into your actual object under test. And you see, if your builder and/or the object under test is dealing with so many attributes that it seems are hard to separate the to -- maybe the better answer would be ... to redesign the whole thing, and come up with more components that are less tightly coupled. – GhostCat Oct 17 '15 at 00:53
  • @Jägermeister yes I know about mocks, but I want it to return a Object of class which has only one constructor taking the builder itself. (If I have understood what you mean correctly) – Sneh Oct 17 '15 at 00:57
  • This response [link](http://stackoverflow.com/questions/90002/what-is-a-reasonable-code-coverage-for-unit-tests-and-why) on stackoverflow gives a nice perspective on unit testing coverage. – Alek Slodowska Oct 17 '15 at 11:29

1 Answers1

0

Ideally you should unit test all your classes. However in practice this may mean a lot of work and little return on your investment. So you have to use your judgement.

In this case, I would say that if your Builder class is non-trivial then I would unit test that first. Once you are confident it is working correctly, ie. all tests pass, then I would unit test the class that it builds.

dave
  • 11,641
  • 5
  • 47
  • 65
  • So you mean there is no hard and fast approach for this? Or it is just to handle my scenario. – Sneh Oct 17 '15 at 00:00
  • 1
    I've found there is no hard and fast approach to engineering. You must use your judgement and weigh the pros and cons of your approach. The first part of my answer is a general rule of thumb. The second part is how I would I apply it to your situation (not having seen any of your code). – dave Oct 17 '15 at 00:12