DevPinoy.org
A Filipino Developers Community
jokiz » Encapsulation vs Testability

>>> First two to make 3 wins! <<<

Encapsulation vs Testability
Reference articles:

  1. Why use private or protected
  2. Testability

I am fond of Rocky Lhotka's CSLA framework before and when i shifted to be test-driven, there are some constructs in CSLA that i'm beginning to dislike.  I like the broken rule tracking, n-tier ready setup, etc. but i'm beginning to hate the static creation methods and having the default constructor as private.  CSLA is very good in encapsulation and i really think that encapsulation sometimes (or maybe oftentimes) sacrifices testability.

The first article (Why use private or protected) appealed to me when i was refactoring a method using some other private methods.  I know that you should only do black box testing but if the test for the exposed method fails, i know that the error can be anywhere in it and also in the private methods that it is using.  Having a separate test for each method can easily pinpoint a breaking change.  I decided to expose these private methods so they can have their accompanying automated unit tests.  I am beginning to have this dilemma if i am designing classes to be testable, do i need to have to use private or protected?  I agree that developing frameworks is an exemption to this rule but oftentimes, we are just developing applications.

The second article basically demonstrates his own metrics for testability.

I used to be fan of a class with readonly properties set-able only in the class' constructor.  My purpose for designing classes like this is i want to have a restriction that all the properties which are required first to be set before fully constructing an instance of the said class.  I found my previous design to be too restrictive when you are designing classes to be testable.  My usual approach these days is to have those properties as read-write and have some broken rule tracking in the class similar to CSLA's BrokenRulesCollection.
Posted 09-14-2006 7:39 PM by jokiz
Filed under: , ,

Comments

cruizer wrote re: Encapsulation vs Testability
on 09-14-2006 4:14 AM
hi jokiz, first the good news: tin lim of MS is interested in having a TDD session for professionals. :P anyway, if you subscribe to the view that TDD is a design methodology, not a testing methodology, you can think of having your methods set as public while you're testing them. once you've tested them and made sure they're working (in isolation), you can set them private and focus on testing them through the public methods that eventually call them. of course you'll have to refactor/change your tests, but then the tests are just artifacts of the TDD process, right? :)
jokiz wrote re: Encapsulation vs Testability
on 09-14-2006 4:25 AM

tdd session - finally!

and what if i plan to revise the said private method again in the future?  i have to re-add the test for it and remove it again?  that's tedious for me.  i'd rather leave them exposed and functioning correctly as i expect them to.

cruizer wrote re: Encapsulation vs Testability
on 09-14-2006 6:56 AM
well ideally...you should test only the public methods (as if matetest mo naman yun private methods, hehheh). so you should exercise the code in the private methods through the public methods that call them. i dunno, maybe by the time you actually set them private you would have refactored to a better design by that time...anyway if you can give an example, maybe we can pair-program from there, di ba :P
jop wrote re: Encapsulation vs Testability
on 09-14-2006 6:57 AM
Someone in the TDD mailing list once posted his opinion about private methods being members of another class just waiting to be born. If you follow that line of thought, "private methods" can be made testable by making them public in another class, thus, making them testable. Without seeing your code, I can not be sure if that premise holds true; but in my code, it seems to be that way. I usually find out that I need to #region a block of private helper methods. Once I've got a few methods organized that I way, I realized that it might be better to just do an Extract Class instead. I usually end up with a class extracted without tests. Initially, that's OK because it was extracted from a class that is covered by tests. Eventually, there comes a need to either modify/understand the code; that gives me a sign that the class needs to have its own tests.
jop wrote re: Encapsulation vs Testability
on 09-14-2006 7:20 AM
Is it just me, or has someone else in here notice that CSLA business objects seem to violate Robert Martin's Single Responsibility Principle? It handles business logic, persistence, validation, undoing, and a whole boat load of stuff that you might not need. Can you still call that encapsulation? Crack open Martin Fowler's Refactoring (be careful of the binding. mine's about to give way) and look at the smells. It seems to have a certain scent: Refused Bequest? Speculative Generality? Whatever it is, I'm not using it voluntarily unless I'm forced not to do TDD. :-).
cruizer wrote re: Encapsulation vs Testability
on 09-14-2006 7:03 PM
same sentiments here jop. feeling ko heavyweight ang CSLA.NET objects.
jokiz wrote re: Encapsulation vs Testability
on 09-14-2006 7:33 PM

jop: i agree on the private methods being members of another class just waiting to be born. i've seen it also in one of the comments in the above article.  but for me, i think even if it is just a part of some class, i'm still willing to expose them just to have their own test  rather than relying on the test of the exposed interface.

re: CSLA, i also agree when it comes to testability.  eh shempre before di naman ako testdriven so i am very fond of it.

smash wrote re: Encapsulation vs Testability
on 09-19-2006 1:54 PM
jop: i once stated that i was not very comfortable with CSLA for probably the same reasons you mentioned and i dont even know what SRP is all about. jokiz did burn me for saying that, since i dont even know how to respond at that time. :) jokiz: sorry bro cant help it, peace! :)
jokiz wrote re: Encapsulation vs Testability
on 09-19-2006 7:45 PM

smash: i did burn you?  where is that?  even cruizer here was once fond of csla and i still do.  it just fails for being testable because of the static methods and its coupling.

re: SRP, the business objects are somewhat bloated because it was designed to be n-tier capable.  it's a trade off and bearable at times.  with regard to the persistence, the BO has the slot for the persistence methods but they can have someone else do the persistence but then they still have to pass the bo attributes.


Copyright DevPinoy 2005-2008