Thread: [Springnet-developer] Object creation invoking protected constructors?
Brought to you by:
aseovic,
markpollack
Menu
▾
▴
springnet-developer
|
From: Erich E. <E.E...@di...> - 2007-09-09 10:36:39
|
Steinar on the forum asked this here: = http://forum.springframework.net/showthread.php?t=3D3448 =20 I'd like to revisit the design decision to not allow accessing = non-public types/constructors/methods/properties and hear your opinions = on this. =20 I recently ran into this issue myself when trying to provide a DI = capable wrapper for "System.Web.UI.SimpleHandlerFactory" from System.Web = assembly. This type is internal and can't be instantiated using Spring = which required to implement a (non-trivial) workaround. The easy way = would be to remove the restriction to public types. =20 I know of opinions out there to don't enforce any restrictions within = the framework. Developers should know what they are doing and if someone = wants to instantiate a non-public type, let him do it at his own risk. =20 Other opinions? =20 cheers, Erich =20 |
|
From: Trudel, S. <ste...@ba...> - 2007-09-11 11:39:58
|
Related question ... does Spring.Net support object construction for objects with internal constructors? If one does not want the instantiation of an object to be allowed outside the scope of a module for purposes of conceptual integrity or otherwise then Spring.Net should support its construction in my opinion ... seem somewhat awkward when class design is influenced by a framework ... ________________________________ From: spr...@li... [mailto:spr...@li...] On Behalf Of Erich Eichinger Sent: Sunday, September 09, 2007 6:36 AM To: springnet-developer Subject: [Springnet-developer] Object creation invoking protected constructors? Steinar on the forum asked this here: http://forum.springframework.net/showthread.php?t=3448 I'd like to revisit the design decision to not allow accessing non-public types/constructors/methods/properties and hear your opinions on this. I recently ran into this issue myself when trying to provide a DI capable wrapper for "System.Web.UI.SimpleHandlerFactory" from System.Web assembly. This type is internal and can't be instantiated using Spring which required to implement a (non-trivial) workaround. The easy way would be to remove the restriction to public types. I know of opinions out there to don't enforce any restrictions within the framework. Developers should know what they are doing and if someone wants to instantiate a non-public type, let him do it at his own risk. Other opinions? cheers, Erich |
|
From: Erich E. <E.E...@di...> - 2007-09-11 11:44:28
|
Hi Stepen, =20 playing the "advocatus diaboli" now: How do you write tests for this = class then? If your design does not allow for instantiating the class, = why should Spring be allowed to? =20 -Erich ________________________________ From: spr...@li... = [mailto:spr...@li...] On Behalf Of = Trudel, Stephen Sent: Tuesday, September 11, 2007 1:40 PM To: Erich Eichinger; springnet-developer Subject: Re: [Springnet-developer] Object creation invokingprotected = constructors? =09 =09 Related question ... does Spring.Net support object construction for = objects with internal constructors? If one does not want the = instantiation of an object to be allowed outside the scope of a module = for purposes of conceptual integrity or otherwise then Spring.Net should = support its construction in my opinion ... seem somewhat awkward when = class design is influenced by a framework ...=20 =09 =20 ________________________________ From: spr...@li... = [mailto:spr...@li...] On Behalf Of = Erich Eichinger Sent: Sunday, September 09, 2007 6:36 AM To: springnet-developer Subject: [Springnet-developer] Object creation invoking protected = constructors? =09 =09 Steinar on the forum asked this here: = http://forum.springframework.net/showthread.php?t=3D3448 =20 I'd like to revisit the design decision to not allow accessing = non-public types/constructors/methods/properties and hear your opinions = on this. =20 I recently ran into this issue myself when trying to provide a DI = capable wrapper for "System.Web.UI.SimpleHandlerFactory" from System.Web = assembly. This type is internal and can't be instantiated using Spring = which required to implement a (non-trivial) workaround. The easy way = would be to remove the restriction to public types. =20 I know of opinions out there to don't enforce any restrictions within = the framework. Developers should know what they are doing and if someone = wants to instantiate a non-public type, let him do it at his own risk. =20 Other opinions? =20 cheers, Erich =20 |
|
From: Bruno B. <br...@gm...> - 2007-09-11 12:02:09
|
Hi, To do that, Microsoft uses their new feature in .NET 2.0 : the InternalsVisibleTo attribute to specify the assembly to which all nonpublic types are to be made visible. (Take a look to System.ServiceModel.dll for an example.) I've also read somewhere MS uses reflection to testes non visible classes too. Anyway, I'm really not a fan of that InternalsVisibleToAttribute because everything becomes internal now... Bruno 2007/9/11, Erich Eichinger <E.E...@di...>: > > Hi Stepen, > > playing the "advocatus diaboli" now: How do you write tests for this class > then? If your design does not allow for instantiating the class, why should > Spring be allowed to? > > -Erich > > ------------------------------ > *From:* spr...@li... [mailto: > spr...@li...] *On Behalf Of *Trudel, > Stephen > *Sent:* Tuesday, September 11, 2007 1:40 PM > *To:* Erich Eichinger; springnet-developer > *Subject:* Re: [Springnet-developer] Object creation invokingprotected > constructors? > > > Related question ... does Spring.Net support object construction for > objects with *internal* constructors? If one does not want the > instantiation of an object to be allowed outside the scope of a module for > purposes of conceptual integrity or otherwise then Spring.Net should > support its construction in my opinion ... seem somewhat awkward when > class design is influenced by a framework ... > > > ------------------------------ > *From:* spr...@li... [mailto: > spr...@li...] *On Behalf Of *Erich > Eichinger > *Sent:* Sunday, September 09, 2007 6:36 AM > *To:* springnet-developer > *Subject:* [Springnet-developer] Object creation invoking protected > constructors? > > > Steinar on the forum asked this here: > http://forum.springframework.net/showthread.php?t=3448 > > I'd like to revisit the design decision to not allow accessing non-public > types/constructors/methods/properties and hear your opinions on this. > > I recently ran into this issue myself when trying to provide a DI capable > wrapper for "System.Web.UI.SimpleHandlerFactory" from System.Web assembly. > This type is internal and can't be instantiated using Spring which required > to implement a (non-trivial) workaround. The easy way would be to remove the > restriction to public types. > > I know of opinions out there to don't enforce any restrictions within the > framework. Developers should know what they are doing and if someone wants > to instantiate a non-public type, let him do it at his own risk. > > Other opinions? > > cheers, > Erich > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Springnet-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springnet-developer > > |
|
From: Erich E. <E.E...@di...> - 2007-09-11 12:11:25
|
Hi, =20 Personally I'm also not a big fan of making everything internal. Even = more, I think that writing tests for my classes *outside* the assembly = is a really good way for driving the design. I *want* my tests to = influence the design (that's what TDD is all about I guess).=20 =20 Although I think Spring should somewhat enforce what we think are best = practices, the world is not always ideal and there are situations where = I wished that Spring supported accessing non-public code. =20 -Erich =20 =20 ________________________________ From: spr...@li... = [mailto:spr...@li...] On Behalf Of = Bruno Baia Sent: Tuesday, September 11, 2007 2:02 PM To: Erich Eichinger Cc: springnet-developer Subject: Re: [Springnet-developer] Object creation = invokingprotectedconstructors? =09 =09 Hi, =20 To do that, Microsoft uses their new feature in .NET 2.0 : the = InternalsVisibleTo attribute to specify the assembly to which all = nonpublic types are to be made visible. (Take a look to = System.ServiceModel.dll for an example.)=20 I've also read somewhere MS uses reflection to testes non visible = classes too. =20 Anyway, I'm really not a fan of that InternalsVisibleToAttribute = because everything becomes internal now... =20 =20 Bruno =09 =20 2007/9/11, Erich Eichinger <E.E...@di...>:=20 Hi Stepen, =20 playing the "advocatus diaboli" now: How do you write tests for this = class then? If your design does not allow for instantiating the class, = why should Spring be allowed to?=20 =20 -Erich ________________________________ From: spr...@li... = [mailto:spr...@li...] On Behalf Of = Trudel, Stephen Sent: Tuesday, September 11, 2007 1:40 PM To: Erich Eichinger; springnet-developer Subject: Re: [Springnet-developer] Object creation invokingprotected = constructors? =09 =20 =09 Related question ... does Spring.Net support object construction for = objects with internal constructors? If one does not want the = instantiation of an object to be allowed outside the scope of a module = for purposes of conceptual integrity or otherwise then Spring.Net = should support its construction in my opinion ... seem somewhat awkward = when class design is influenced by a framework ...=20 =09 =20 ________________________________ From: spr...@li... = [mailto:spr...@li...] On Behalf Of = Erich Eichinger Sent: Sunday, September 09, 2007 6:36 AM To: springnet-developer Subject: [Springnet-developer] Object creation invoking protected = constructors? =09 =20 Steinar on the forum asked this here: = http://forum.springframework.net/showthread.php?t=3D3448 =20 I'd like to revisit the design decision to not allow accessing = non-public types/constructors/methods/properties and hear your opinions = on this.=20 =20 I recently ran into this issue myself when trying to provide a DI = capable wrapper for "System.Web.UI.SimpleHandlerFactory" from System.Web = assembly. This type is internal and can't be instantiated using Spring = which required to implement a (non-trivial) workaround. The easy way = would be to remove the restriction to public types.=20 =20 I know of opinions out there to don't enforce any restrictions within = the framework. Developers should know what they are doing and if someone = wants to instantiate a non-public type, let him do it at his own risk.=20 =20 Other opinions? =20 cheers, Erich =20 = -------------------------------------------------------------------------= This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005.=20 http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________=20 Springnet-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springnet-developer =09 =09 |
|
From: Trudel, S. <ste...@ba...> - 2007-09-11 12:19:49
|
The goals of TDD can be achieved as easily when the tests are inside the assembly. ________________________________ From: spr...@li... [mailto:spr...@li...] On Behalf Of Erich Eichinger Sent: Tuesday, September 11, 2007 8:10 AM To: Bruno Baia; springnet-developer Subject: Re: [Springnet-developer] Object creation invokingprotectedconstructors? Hi, Personally I'm also not a big fan of making everything internal. Even more, I think that writing tests for my classes *outside* the assembly is a really good way for driving the design. I *want* my tests to influence the design (that's what TDD is all about I guess). Although I think Spring should somewhat enforce what we think are best practices, the world is not always ideal and there are situations where I wished that Spring supported accessing non-public code. -Erich ________________________________ From: spr...@li... [mailto:spr...@li...] On Behalf Of Bruno Baia Sent: Tuesday, September 11, 2007 2:02 PM To: Erich Eichinger Cc: springnet-developer Subject: Re: [Springnet-developer] Object creation invokingprotectedconstructors? Hi, To do that, Microsoft uses their new feature in .NET 2.0 : the InternalsVisibleTo attribute to specify the assembly to which all nonpublic types are to be made visible. (Take a look to System.ServiceModel.dll for an example.) I've also read somewhere MS uses reflection to testes non visible classes too. Anyway, I'm really not a fan of that InternalsVisibleToAttribute because everything becomes internal now... Bruno 2007/9/11, Erich Eichinger <E.E...@di...>: Hi Stepen, playing the "advocatus diaboli" now: How do you write tests for this class then? If your design does not allow for instantiating the class, why should Spring be allowed to? -Erich ________________________________ From: spr...@li... [mailto:spr...@li...] On Behalf Of Trudel, Stephen Sent: Tuesday, September 11, 2007 1:40 PM To: Erich Eichinger; springnet-developer Subject: Re: [Springnet-developer] Object creation invokingprotected constructors? Related question ... does Spring.Net support object construction for objects with internal constructors? If one does not want the instantiation of an object to be allowed outside the scope of a module for purposes of conceptual integrity or otherwise then Spring.Net should support its construction in my opinion ... seem somewhat awkward when class design is influenced by a framework ... ________________________________ From: spr...@li... [mailto:spr...@li...] On Behalf Of Erich Eichinger Sent: Sunday, September 09, 2007 6:36 AM To: springnet-developer Subject: [Springnet-developer] Object creation invoking protected constructors? Steinar on the forum asked this here: http://forum.springframework.net/showthread.php?t=3448 I'd like to revisit the design decision to not allow accessing non-public types/constructors/methods/properties and hear your opinions on this. I recently ran into this issue myself when trying to provide a DI capable wrapper for "System.Web.UI.SimpleHandlerFactory" from System.Web assembly. This type is internal and can't be instantiated using Spring which required to implement a (non-trivial) workaround. The easy way would be to remove the restriction to public types. I know of opinions out there to don't enforce any restrictions within the framework. Developers should know what they are doing and if someone wants to instantiate a non-public type, let him do it at his own risk. Other opinions? cheers, Erich ------------------------------------------------------------------------ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Springnet-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springnet-developer |
|
From: Mark P. <mpo...@in...> - 2007-09-11 17:42:22
|
Hi, I can see the +'s of allowing it, i.e. if a developer *really* needs to go under the covers to get something to work, we shouldn't get in the way, and the -'s of doing it, you subvert the intention of the original designer of the class. How about we provide a top level attribute to the <objects> element that allow for one to call protected constructors and appropriate API changes to the context classes. This way, the default is not to allow it, but if you need it, the requirements is made explicitly and the contract is global. It also keeps the solutions simple, i.e. not per object functionality. An additional question, should one also allow calling of protected properties, private ctor/properties? Probably something along the lines of xor'ing of binding properties would make sense if we want to go down that path. I'd guess that in some cases, people don't like having the test .dll dependencies within the 'production' assembly that gets shiped to clients, so tests are placed in a separate assembly. Cheers, Mark From: spr...@li... [mailto:spr...@li...] On Behalf Of Trudel, Stephen Sent: Tuesday, September 11, 2007 8:19 AM To: Erich Eichinger; Bruno Baia; springnet-developer Subject: Re: [Springnet-developer] Object creation invokingprotectedconstructors? The goals of TDD can be achieved as easily when the tests are inside the assembly. _____ From: spr...@li... [mailto:spr...@li...] On Behalf Of Erich Eichinger Sent: Tuesday, September 11, 2007 8:10 AM To: Bruno Baia; springnet-developer Subject: Re: [Springnet-developer] Object creation invokingprotectedconstructors? Hi, Personally I'm also not a big fan of making everything internal. Even more, I think that writing tests for my classes *outside* the assembly is a really good way for driving the design. I *want* my tests to influence the design (that's what TDD is all about I guess). Although I think Spring should somewhat enforce what we think are best practices, the world is not always ideal and there are situations where I wished that Spring supported accessing non-public code. -Erich _____ From: spr...@li... [mailto:spr...@li...] On Behalf Of Bruno Baia Sent: Tuesday, September 11, 2007 2:02 PM To: Erich Eichinger Cc: springnet-developer Subject: Re: [Springnet-developer] Object creation invokingprotectedconstructors? Hi, To do that, Microsoft uses their new feature in .NET 2.0 : the InternalsVisibleTo attribute to specify the assembly to which all nonpublic types are to be made visible. (Take a look to System.ServiceModel.dll for an example.) I've also read somewhere MS uses reflection to testes non visible classes too. Anyway, I'm really not a fan of that InternalsVisibleToAttribute because everything becomes internal now... Bruno 2007/9/11, Erich Eichinger <E.E...@di...>: Hi Stepen, playing the "advocatus diaboli" now: How do you write tests for this class then? If your design does not allow for instantiating the class, why should Spring be allowed to? -Erich _____ From: spr...@li... [mailto:spr...@li...] On Behalf Of Trudel, Stephen Sent: Tuesday, September 11, 2007 1:40 PM To: Erich Eichinger; springnet-developer Subject: Re: [Springnet-developer] Object creation invokingprotected constructors? Related question ... does Spring.Net support object construction for objects with internal constructors? If one does not want the instantiation of an object to be allowed outside the scope of a module for purposes of conceptual integrity or otherwise then Spring.Net should support its construction in my opinion ... seem somewhat awkward when class design is influenced by a framework ... _____ From: spr...@li... [mailto:spr...@li...] On Behalf Of Erich Eichinger Sent: Sunday, September 09, 2007 6:36 AM To: springnet-developer Subject: [Springnet-developer] Object creation invoking protected constructors? Steinar on the forum asked this here: http://forum.springframework.net/showthread.php?t=3448 I'd like to revisit the design decision to not allow accessing non-public types/constructors/methods/properties and hear your opinions on this. I recently ran into this issue myself when trying to provide a DI capable wrapper for "System.Web.UI.SimpleHandlerFactory" from System.Web assembly. This type is internal and can't be instantiated using Spring which required to implement a (non-trivial) workaround. The easy way would be to remove the restriction to public types. I know of opinions out there to don't enforce any restrictions within the framework. Developers should know what they are doing and if someone wants to instantiate a non-public type, let him do it at his own risk. Other opinions? cheers, Erich ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Springnet-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springnet-developer |
|
From: Trudel, S. <ste...@ba...> - 2007-09-11 18:52:15
|
Mark, I think most of us agree if developers are invoking non-public members on classes they did not create then they are doing so at their own risk. I think there is an argument that perhaps is being overlooked or I did not read everyone posts carefully. If so I apologize. Consider if you are the class designer, your classes have internal members by design, and today you are NOT using Spring. Tomorrow you decide to use Spring and you now have to change your class design. That seems intrusive. I really like your idea for top level attribute to the objects element ... its explicit. Whether the tests can shipped to production or not depends in part on if you promote source or promote binaries through the promotion pipeline. Our releases (QA, UAT, PROD) are done by another group who for audit reasons CANNOT promote binaries (rule only applies to PROD but we follow the same process regardless). This group must build the application from version control. Based on certain conditions (e.g. non-DEV build) we can turn on or off a compilation switch resulting in our unit tests being excluded from a release. There are other approaches to achieve this exclusion as well. Clearly there are tradeoffs to consider. In my experience no one has convinced me that tests residing in the same assembly is a bad practice. Regards, Stephen ________________________________ From: Mark Pollack [mailto:mpo...@in...] Sent: Tuesday, September 11, 2007 1:42 PM To: Trudel, Stephen; 'Erich Eichinger'; 'Bruno Baia'; 'springnet-developer' Subject: RE: [Springnet-developer] Object creation invokingprotectedconstructors? Hi, I can see the +'s of allowing it, i.e. if a developer *really* needs to go under the covers to get something to work, we shouldn't get in the way, and the -'s of doing it, you subvert the intention of the original designer of the class. How about we provide a top level attribute to the <objects> element that allow for one to call protected constructors and appropriate API changes to the context classes. This way, the default is not to allow it, but if you need it, the requirements is made explicitly and the contract is global. It also keeps the solutions simple, i.e. not per object functionality. An additional question, should one also allow calling of protected properties, private ctor/properties? Probably something along the lines of xor'ing of binding properties would make sense if we want to go down that path. I'd guess that in some cases, people don't like having the test .dll dependencies within the 'production' assembly that gets shiped to clients, so tests are placed in a separate assembly. Cheers, Mark From: spr...@li... [mailto:spr...@li...] On Behalf Of Trudel, Stephen Sent: Tuesday, September 11, 2007 8:19 AM To: Erich Eichinger; Bruno Baia; springnet-developer Subject: Re: [Springnet-developer] Object creation invokingprotectedconstructors? The goals of TDD can be achieved as easily when the tests are inside the assembly. ________________________________ From: spr...@li... [mailto:spr...@li...] On Behalf Of Erich Eichinger Sent: Tuesday, September 11, 2007 8:10 AM To: Bruno Baia; springnet-developer Subject: Re: [Springnet-developer] Object creation invokingprotectedconstructors? Hi, Personally I'm also not a big fan of making everything internal. Even more, I think that writing tests for my classes *outside* the assembly is a really good way for driving the design. I *want* my tests to influence the design (that's what TDD is all about I guess). Although I think Spring should somewhat enforce what we think are best practices, the world is not always ideal and there are situations where I wished that Spring supported accessing non-public code. -Erich ________________________________ From: spr...@li... [mailto:spr...@li...] On Behalf Of Bruno Baia Sent: Tuesday, September 11, 2007 2:02 PM To: Erich Eichinger Cc: springnet-developer Subject: Re: [Springnet-developer] Object creation invokingprotectedconstructors? Hi, To do that, Microsoft uses their new feature in .NET 2.0 : the InternalsVisibleTo attribute to specify the assembly to which all nonpublic types are to be made visible. (Take a look to System.ServiceModel.dll for an example.) I've also read somewhere MS uses reflection to testes non visible classes too. Anyway, I'm really not a fan of that InternalsVisibleToAttribute because everything becomes internal now... Bruno 2007/9/11, Erich Eichinger <E.E...@di...>: Hi Stepen, playing the "advocatus diaboli" now: How do you write tests for this class then? If your design does not allow for instantiating the class, why should Spring be allowed to? -Erich ________________________________ From: spr...@li... [mailto:spr...@li...] On Behalf Of Trudel, Stephen Sent: Tuesday, September 11, 2007 1:40 PM To: Erich Eichinger; springnet-developer Subject: Re: [Springnet-developer] Object creation invokingprotected constructors? Related question ... does Spring.Net support object construction for objects with internal constructors? If one does not want the instantiation of an object to be allowed outside the scope of a module for purposes of conceptual integrity or otherwise then Spring.Net should support its construction in my opinion ... seem somewhat awkward when class design is influenced by a framework ... ________________________________ From: spr...@li... [mailto:spr...@li...] On Behalf Of Erich Eichinger Sent: Sunday, September 09, 2007 6:36 AM To: springnet-developer Subject: [Springnet-developer] Object creation invoking protected constructors? Steinar on the forum asked this here: http://forum.springframework.net/showthread.php?t=3448 I'd like to revisit the design decision to not allow accessing non-public types/constructors/methods/properties and hear your opinions on this. I recently ran into this issue myself when trying to provide a DI capable wrapper for "System.Web.UI.SimpleHandlerFactory" from System.Web assembly. This type is internal and can't be instantiated using Spring which required to implement a (non-trivial) workaround. The easy way would be to remove the restriction to public types. I know of opinions out there to don't enforce any restrictions within the framework. Developers should know what they are doing and if someone wants to instantiate a non-public type, let him do it at his own risk. Other opinions? cheers, Erich ------------------------------------------------------------------------ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Springnet-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springnet-developer |
|
From: Mark P. <mpo...@in...> - 2007-09-11 22:23:51
|
Hi Stephen, Yup, at your own risk pretty much summarizes what I think is going on here. I'd hope that this is a rare case since if one was developing an API for public consumption one would assume it has enough functionality marked as public so that it is amenable to instantiate configuration via its public API, either via 'new' or via dedicated factory objects. I also see your point with environments putting constraints on where test cases reside, I wasn't trying to imply a 'best way' as usually the best way is dependent on many many things, such as how you migrate to PROD, shipping policies.sometimes it is just the whim of a point-haired manager J Anyway, I realize my email might have been a bit terse/aggressive, that wasn't my intention, just trying to sneak in a few emails on my vacation. Cheers, Mark From: Trudel, Stephen [mailto:ste...@ba...] Sent: Tuesday, September 11, 2007 2:52 PM To: Mark Pollack; Erich Eichinger; Bruno Baia; springnet-developer Subject: RE: [Springnet-developer] Object creation invokingprotectedconstructors? Mark, I think most of us agree if developers are invoking non-public members on classes they did not create then they are doing so at their own risk. I think there is an argument that perhaps is being overlooked or I did not read everyone posts carefully. If so I apologize. Consider if you are the class designer, your classes have internal members by design, and today you are NOT using Spring. Tomorrow you decide to use Spring and you now have to change your class design. That seems intrusive. I really like your idea for top level attribute to the objects element ... its explicit. Whether the tests can shipped to production or not depends in part on if you promote source or promote binaries through the promotion pipeline. Our releases (QA, UAT, PROD) are done by another group who for audit reasons CANNOT promote binaries (rule only applies to PROD but we follow the same process regardless). This group must build the application from version control. Based on certain conditions (e.g. non-DEV build) we can turn on or off a compilation switch resulting in our unit tests being excluded from a release. There are other approaches to achieve this exclusion as well. Clearly there are tradeoffs to consider. In my experience no one has convinced me that tests residing in the same assembly is a bad practice. Regards, Stephen _____ From: Mark Pollack [mailto:mpo...@in...] Sent: Tuesday, September 11, 2007 1:42 PM To: Trudel, Stephen; 'Erich Eichinger'; 'Bruno Baia'; 'springnet-developer' Subject: RE: [Springnet-developer] Object creation invokingprotectedconstructors? Hi, I can see the +'s of allowing it, i.e. if a developer *really* needs to go under the covers to get something to work, we shouldn't get in the way, and the -'s of doing it, you subvert the intention of the original designer of the class. How about we provide a top level attribute to the <objects> element that allow for one to call protected constructors and appropriate API changes to the context classes. This way, the default is not to allow it, but if you need it, the requirements is made explicitly and the contract is global. It also keeps the solutions simple, i.e. not per object functionality. An additional question, should one also allow calling of protected properties, private ctor/properties? Probably something along the lines of xor'ing of binding properties would make sense if we want to go down that path. I'd guess that in some cases, people don't like having the test .dll dependencies within the 'production' assembly that gets shiped to clients, so tests are placed in a separate assembly. Cheers, Mark From: spr...@li... [mailto:spr...@li...] On Behalf Of Trudel, Stephen Sent: Tuesday, September 11, 2007 8:19 AM To: Erich Eichinger; Bruno Baia; springnet-developer Subject: Re: [Springnet-developer] Object creation invokingprotectedconstructors? The goals of TDD can be achieved as easily when the tests are inside the assembly. _____ From: spr...@li... [mailto:spr...@li...] On Behalf Of Erich Eichinger Sent: Tuesday, September 11, 2007 8:10 AM To: Bruno Baia; springnet-developer Subject: Re: [Springnet-developer] Object creation invokingprotectedconstructors? Hi, Personally I'm also not a big fan of making everything internal. Even more, I think that writing tests for my classes *outside* the assembly is a really good way for driving the design. I *want* my tests to influence the design (that's what TDD is all about I guess). Although I think Spring should somewhat enforce what we think are best practices, the world is not always ideal and there are situations where I wished that Spring supported accessing non-public code. -Erich _____ From: spr...@li... [mailto:spr...@li...] On Behalf Of Bruno Baia Sent: Tuesday, September 11, 2007 2:02 PM To: Erich Eichinger Cc: springnet-developer Subject: Re: [Springnet-developer] Object creation invokingprotectedconstructors? Hi, To do that, Microsoft uses their new feature in .NET 2.0 : the InternalsVisibleTo attribute to specify the assembly to which all nonpublic types are to be made visible. (Take a look to System.ServiceModel.dll for an example.) I've also read somewhere MS uses reflection to testes non visible classes too. Anyway, I'm really not a fan of that InternalsVisibleToAttribute because everything becomes internal now... Bruno 2007/9/11, Erich Eichinger <E.E...@di...>: Hi Stepen, playing the "advocatus diaboli" now: How do you write tests for this class then? If your design does not allow for instantiating the class, why should Spring be allowed to? -Erich _____ From: spr...@li... [mailto:spr...@li...] On Behalf Of Trudel, Stephen Sent: Tuesday, September 11, 2007 1:40 PM To: Erich Eichinger; springnet-developer Subject: Re: [Springnet-developer] Object creation invokingprotected constructors? Related question ... does Spring.Net support object construction for objects with internal constructors? If one does not want the instantiation of an object to be allowed outside the scope of a module for purposes of conceptual integrity or otherwise then Spring.Net should support its construction in my opinion ... seem somewhat awkward when class design is influenced by a framework ... _____ From: spr...@li... [mailto:spr...@li...] On Behalf Of Erich Eichinger Sent: Sunday, September 09, 2007 6:36 AM To: springnet-developer Subject: [Springnet-developer] Object creation invoking protected constructors? Steinar on the forum asked this here: http://forum.springframework.net/showthread.php?t=3448 I'd like to revisit the design decision to not allow accessing non-public types/constructors/methods/properties and hear your opinions on this. I recently ran into this issue myself when trying to provide a DI capable wrapper for "System.Web.UI.SimpleHandlerFactory" from System.Web assembly. This type is internal and can't be instantiated using Spring which required to implement a (non-trivial) workaround. The easy way would be to remove the restriction to public types. I know of opinions out there to don't enforce any restrictions within the framework. Developers should know what they are doing and if someone wants to instantiate a non-public type, let him do it at his own risk. Other opinions? cheers, Erich ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Springnet-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springnet-developer |
|
From: Trudel, S. <ste...@ba...> - 2007-09-12 12:50:34
|
Mark,
As we all know, the whole point is to allow separation the abstraction
from its implementation so the two can vary independently (GoF, Bridge
Pattern) ... that is great and I am glad Spring helps to apply this
pattern declaratively.
The question is one of scope. By design do we want client code outside
the physical assembly ("external code") to inject implementations? The
answer to this question is rarely yes in my opinion so I agree with you.
- Maybe allowing external code to inject would do more harm than good.
Rare? Yes.
- Maybe it just does not make sense for external code to provide the
implementation but for testing purposes the developer want to swap in a
separate mock implementation.
- etc
I think a more important question is do these circumstances exist? I
think they do.
I did not interpret your email as aggressive at all with regard to unit
test placement.
Regards,
Stephen
________________________________
From: Mark Pollack [mailto:mpo...@in...]
Sent: Tuesday, September 11, 2007 6:23 PM
To: Trudel, Stephen; 'Erich Eichinger'; 'Bruno Baia';
'springnet-developer'
Subject: RE: [Springnet-developer] Object creation
invokingprotectedconstructors?
Hi Stephen,
Yup, at your own risk pretty much summarizes what I think is going on
here. I'd hope that this is a rare case since if one was developing an
API for public consumption one would assume it has enough functionality
marked as public so that it is amenable to instantiate configuration via
its public API, either via 'new' or via dedicated factory objects. I
also see your point with environments putting constraints on where test
cases reside, I wasn't trying to imply a 'best way' as usually the best
way is dependent on many many things, such as how you migrate to PROD,
shipping policies...sometimes it is just the whim of a point-haired
manager J Anyway, I realize my email might have been a bit
terse/aggressive, that wasn't my intention, just trying to sneak in a
few emails on my vacation.
Cheers,
Mark
From: Trudel, Stephen [mailto:ste...@ba...]
Sent: Tuesday, September 11, 2007 2:52 PM
To: Mark Pollack; Erich Eichinger; Bruno Baia; springnet-developer
Subject: RE: [Springnet-developer] Object creation
invokingprotectedconstructors?
Mark,
I think most of us agree if developers are invoking non-public members
on classes they did not create then they are doing so at their own risk.
I think there is an argument that perhaps is being overlooked or I did
not read everyone posts carefully. If so I apologize. Consider if you
are the class designer, your classes have internal members by design,
and today you are NOT using Spring. Tomorrow you decide to use Spring
and you now have to change your class design. That seems intrusive.
I really like your idea for top level attribute to the objects element
... its explicit.
Whether the tests can shipped to production or not depends in part on if
you promote source or promote binaries through the promotion pipeline.
Our releases (QA, UAT, PROD) are done by another group who for audit
reasons CANNOT promote binaries (rule only applies to PROD but we follow
the same process regardless). This group must build the application
from version control. Based on certain conditions (e.g. non-DEV build)
we can turn on or off a compilation switch resulting in our unit tests
being excluded from a release. There are other approaches to achieve
this exclusion as well. Clearly there are tradeoffs to consider. In my
experience no one has convinced me that tests residing in the same
assembly is a bad practice.
Regards,
Stephen
________________________________
From: Mark Pollack [mailto:mpo...@in...]
Sent: Tuesday, September 11, 2007 1:42 PM
To: Trudel, Stephen; 'Erich Eichinger'; 'Bruno Baia';
'springnet-developer'
Subject: RE: [Springnet-developer] Object creation
invokingprotectedconstructors?
Hi,
I can see the +'s of allowing it, i.e. if a developer *really* needs to
go under the covers to get something to work, we shouldn't get in the
way, and the -'s of doing it, you subvert the intention of the original
designer of the class. How about we provide a top level attribute to
the <objects> element that allow for one to call protected constructors
and appropriate API changes to the context classes. This way, the
default is not to allow it, but if you need it, the requirements is made
explicitly and the contract is global. It also keeps the solutions
simple, i.e. not per object functionality.
An additional question, should one also allow calling of protected
properties, private ctor/properties? Probably something along the lines
of xor'ing of binding properties would make sense if we want to go down
that path.
I'd guess that in some cases, people don't like having the test .dll
dependencies within the 'production' assembly that gets shiped to
clients, so tests are placed in a separate assembly.
Cheers,
Mark
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Trudel, Stephen
Sent: Tuesday, September 11, 2007 8:19 AM
To: Erich Eichinger; Bruno Baia; springnet-developer
Subject: Re: [Springnet-developer] Object creation
invokingprotectedconstructors?
The goals of TDD can be achieved as easily when the tests are inside the
assembly.
________________________________
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Erich Eichinger
Sent: Tuesday, September 11, 2007 8:10 AM
To: Bruno Baia; springnet-developer
Subject: Re: [Springnet-developer] Object creation
invokingprotectedconstructors?
Hi,
Personally I'm also not a big fan of making everything internal. Even
more, I think that writing tests for my classes *outside* the assembly
is a really good way for driving the design. I *want* my tests to
influence the design (that's what TDD is all about I guess).
Although I think Spring should somewhat enforce what we think are best
practices, the world is not always ideal and there are situations where
I wished that Spring supported accessing non-public code.
-Erich
________________________________
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Bruno Baia
Sent: Tuesday, September 11, 2007 2:02 PM
To: Erich Eichinger
Cc: springnet-developer
Subject: Re: [Springnet-developer] Object creation
invokingprotectedconstructors?
Hi,
To do that, Microsoft uses their new feature in .NET 2.0 : the
InternalsVisibleTo attribute to specify the assembly to which all
nonpublic types are to be made visible. (Take a look to
System.ServiceModel.dll for an example.)
I've also read somewhere MS uses reflection to testes non
visible classes too.
Anyway, I'm really not a fan of that InternalsVisibleToAttribute
because everything becomes internal now...
Bruno
2007/9/11, Erich Eichinger <E.E...@di...>:
Hi Stepen,
playing the "advocatus diaboli" now: How do you write tests for
this class then? If your design does not allow for instantiating the
class, why should Spring be allowed to?
-Erich
________________________________
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Trudel, Stephen
Sent: Tuesday, September 11, 2007 1:40 PM
To: Erich Eichinger; springnet-developer
Subject: Re: [Springnet-developer] Object creation
invokingprotected constructors?
Related question ... does Spring.Net support object
construction for objects with internal constructors? If one does not
want the instantiation of an object to be allowed outside the scope of a
module for purposes of conceptual integrity or otherwise then Spring.Net
should support its construction in my opinion ... seem somewhat awkward
when class design is influenced by a framework ...
________________________________
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Erich Eichinger
Sent: Sunday, September 09, 2007 6:36 AM
To: springnet-developer
Subject: [Springnet-developer] Object creation invoking
protected constructors?
Steinar on the forum asked this here:
http://forum.springframework.net/showthread.php?t=3448
I'd like to revisit the design decision to not allow
accessing non-public types/constructors/methods/properties and hear your
opinions on this.
I recently ran into this issue myself when trying to
provide a DI capable wrapper for "System.Web.UI.SimpleHandlerFactory"
from System.Web assembly. This type is internal and can't be
instantiated using Spring which required to implement a (non-trivial)
workaround. The easy way would be to remove the restriction to public
types.
I know of opinions out there to don't enforce any
restrictions within the framework. Developers should know what they are
doing and if someone wants to instantiate a non-public type, let him do
it at his own risk.
Other opinions?
cheers,
Erich
------------------------------------------------------------------------
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Springnet-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springnet-developer
|
|
From: Erich E. <E.E...@di...> - 2007-09-12 15:54:08
|
Hi Stephen, =20 agreed that these circumstances exist and I'm pretty sure that everyone = is already more or less convinced, that Spring.NET should support them. = Means +1 from me for supporting non-public classes and their members = (ctor, method, props). =20 What I was trying to say - and I think Mark as well - is, that it drives = your design positively if you place your tests in another assembly, = because the need for testing internal classes is more an exception than = the usual case. Sometimes you find, that you can't test a class because = it is internal - which in general (at least to my experience) is a sign = to rethink the design or it is an implementation detail. I remember when = starting TDD myself, I placed my tests into the same assemblies for the = same reasons you described here. The danger you run into when doing this = is that you might easily overlook that you are testing implementation = details - which makes it hard to change these details later. A lot of = tests later I'm convinced that it is an important instrument for = improving the API of my classes to place the tests into their own = assembly. =20 cheers, Erich ________________________________ From: Trudel, Stephen [mailto:ste...@ba...]=20 Sent: Wednesday, September 12, 2007 2:50 PM To: Mark Pollack; Erich Eichinger; Bruno Baia; springnet-developer Subject: RE: [Springnet-developer] Object creation = invokingprotectedconstructors? =09 =09 Mark, =20 As we all know, the whole point is to allow separation the abstraction = from its implementation so the two can vary independently (GoF, Bridge = Pattern) ... that is great and I am glad Spring helps to apply this = pattern declaratively. =20 The question is one of scope. By design do we want client code outside = the physical assembly ("external code") to inject implementations? The = answer to this question is rarely yes in my opinion so I agree with you. = =20 =20 - Maybe allowing external code to inject would do more harm than good. = Rare? Yes.=20 - Maybe it just does not make sense for external code to provide the = implementation but for testing purposes the developer want to swap in a = separate mock implementation.=20 - etc =20 I think a more important question is do these circumstances exist? I = think they do. =20 =20 I did not interpret your email as aggressive at all with regard to unit = test placement. =20 =20 Regards, Stephen ________________________________ From: Mark Pollack [mailto:mpo...@in...]=20 Sent: Tuesday, September 11, 2007 6:23 PM To: Trudel, Stephen; 'Erich Eichinger'; 'Bruno Baia'; = 'springnet-developer' Subject: RE: [Springnet-developer] Object creation = invokingprotectedconstructors? =09 =09 Hi Stephen, =20 Yup, at your own risk pretty much summarizes what I think is going on = here. I'd hope that this is a rare case since if one was developing an = API for public consumption one would assume it has enough functionality = marked as public so that it is amenable to instantiate configuration via = its public API, either via 'new' or via dedicated factory objects. I = also see your point with environments putting constraints on where test = cases reside, I wasn't trying to imply a 'best way' as usually the best = way is dependent on many many things, such as how you migrate to PROD, = shipping policies...sometimes it is just the whim of a point-haired = manager J Anyway, I realize my email might have been a bit = terse/aggressive, that wasn't my intention, just trying to sneak in a = few emails on my vacation. =20 Cheers, Mark =20 =20 =20 =20 =20 =20 From: Trudel, Stephen [mailto:ste...@ba...]=20 Sent: Tuesday, September 11, 2007 2:52 PM To: Mark Pollack; Erich Eichinger; Bruno Baia; springnet-developer Subject: RE: [Springnet-developer] Object creation = invokingprotectedconstructors? =20 Mark, =20 I think most of us agree if developers are invoking non-public members = on classes they did not create then they are doing so at their own risk. = I think there is an argument that perhaps is being overlooked or I did = not read everyone posts carefully. If so I apologize. Consider if you = are the class designer, your classes have internal members by design, = and today you are NOT using Spring. Tomorrow you decide to use Spring = and you now have to change your class design. That seems intrusive. =20 =20 I really like your idea for top level attribute to the objects element = ... its explicit. =20 =20 Whether the tests can shipped to production or not depends in part on = if you promote source or promote binaries through the promotion = pipeline. Our releases (QA, UAT, PROD) are done by another group who = for audit reasons CANNOT promote binaries (rule only applies to PROD but = we follow the same process regardless). This group must build the = application from version control. Based on certain conditions (e.g. = non-DEV build) we can turn on or off a compilation switch resulting in = our unit tests being excluded from a release. There are other = approaches to achieve this exclusion as well. Clearly there are = tradeoffs to consider. In my experience no one has convinced me that = tests residing in the same assembly is a bad practice. =20 Regards, Stephen =20 ________________________________ From: Mark Pollack [mailto:mpo...@in...]=20 Sent: Tuesday, September 11, 2007 1:42 PM To: Trudel, Stephen; 'Erich Eichinger'; 'Bruno Baia'; = 'springnet-developer' Subject: RE: [Springnet-developer] Object creation = invokingprotectedconstructors? Hi, =20 I can see the +'s of allowing it, i.e. if a developer *really* needs to = go under the covers to get something to work, we shouldn't get in the = way, and the -'s of doing it, you subvert the intention of the original = designer of the class. How about we provide a top level attribute to = the <objects> element that allow for one to call protected constructors = and appropriate API changes to the context classes. This way, the = default is not to allow it, but if you need it, the requirements is made = explicitly and the contract is global. It also keeps the solutions = simple, i.e. not per object functionality. =20 An additional question, should one also allow calling of protected = properties, private ctor/properties? Probably something along the lines = of xor'ing of binding properties would make sense if we want to go down = that path. =20 =20 I'd guess that in some cases, people don't like having the test .dll = dependencies within the 'production' assembly that gets shiped to = clients, so tests are placed in a separate assembly. =20 =20 Cheers, Mark =20 =20 =20 =20 From: spr...@li... = [mailto:spr...@li...] On Behalf Of = Trudel, Stephen Sent: Tuesday, September 11, 2007 8:19 AM To: Erich Eichinger; Bruno Baia; springnet-developer Subject: Re: [Springnet-developer] Object creation = invokingprotectedconstructors? =20 The goals of TDD can be achieved as easily when the tests are inside = the assembly. =20 =20 ________________________________ From: spr...@li... = [mailto:spr...@li...] On Behalf Of = Erich Eichinger Sent: Tuesday, September 11, 2007 8:10 AM To: Bruno Baia; springnet-developer Subject: Re: [Springnet-developer] Object creation = invokingprotectedconstructors? Hi, =20 Personally I'm also not a big fan of making everything internal. Even = more, I think that writing tests for my classes *outside* the assembly = is a really good way for driving the design. I *want* my tests to = influence the design (that's what TDD is all about I guess).=20 =20 Although I think Spring should somewhat enforce what we think are best = practices, the world is not always ideal and there are situations where = I wished that Spring supported accessing non-public code. =20 -Erich =20 =20 =20 ________________________________ From: spr...@li... = [mailto:spr...@li...] On Behalf Of = Bruno Baia Sent: Tuesday, September 11, 2007 2:02 PM To: Erich Eichinger Cc: springnet-developer Subject: Re: [Springnet-developer] Object creation = invokingprotectedconstructors? Hi, =20 To do that, Microsoft uses their new feature in .NET 2.0 : the = InternalsVisibleTo attribute to specify the assembly to which all = nonpublic types are to be made visible. (Take a look to = System.ServiceModel.dll for an example.)=20 I've also read somewhere MS uses reflection to testes non visible = classes too. =20 Anyway, I'm really not a fan of that InternalsVisibleToAttribute = because everything becomes internal now... =20 =20 Bruno =09 =20 2007/9/11, Erich Eichinger <E.E...@di...>:=20 Hi Stepen, =20 playing the "advocatus diaboli" now: How do you write tests for this = class then? If your design does not allow for instantiating the class, = why should Spring be allowed to?=20 =20 -Erich =20 ________________________________ From: spr...@li... = [mailto:spr...@li...] On Behalf Of = Trudel, Stephen Sent: Tuesday, September 11, 2007 1:40 PM To: Erich Eichinger; springnet-developer Subject: Re: [Springnet-developer] Object creation invokingprotected = constructors? =09 =20 Related question ... does Spring.Net support object construction for = objects with internal constructors? If one does not want the = instantiation of an object to be allowed outside the scope of a module = for purposes of conceptual integrity or otherwise then Spring.Net = should support its construction in my opinion ... seem somewhat awkward = when class design is influenced by a framework ...=20 =09 =20 ________________________________ From: spr...@li... = [mailto:spr...@li...] On Behalf Of = Erich Eichinger Sent: Sunday, September 09, 2007 6:36 AM To: springnet-developer Subject: [Springnet-developer] Object creation invoking protected = constructors? =09 =20 Steinar on the forum asked this here: = http://forum.springframework.net/showthread.php?t=3D3448 =20 I'd like to revisit the design decision to not allow accessing = non-public types/constructors/methods/properties and hear your opinions = on this.=20 =20 I recently ran into this issue myself when trying to provide a DI = capable wrapper for "System.Web.UI.SimpleHandlerFactory" from System.Web = assembly. This type is internal and can't be instantiated using Spring = which required to implement a (non-trivial) workaround. The easy way = would be to remove the restriction to public types.=20 =20 I know of opinions out there to don't enforce any restrictions within = the framework. Developers should know what they are doing and if someone = wants to instantiate a non-public type, let him do it at his own risk.=20 =20 Other opinions? =20 cheers, Erich =20 =09 = -------------------------------------------------------------------------= This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005.=20 http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________=20 Springnet-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springnet-developer =20 |
|
From: Trudel, S. <ste...@ba...> - 2007-09-13 13:06:08
|
Erich, I believe Mark was referring to the overhead of excluding the tests at a later time. There are also dangers to having the tests outside the assembly. I often look at open source libraries and wonder why some abstractions which in fact support internal details are made public. Is it so they can be tested? A person using the API has to understand what all these types are for and how they fit together. That can be quite overwhelming. Do we want to muddy the waters with types and members that should be internal? Not if usability and productivity are of utmost importance. I recommend taking a peek inside Reflector for the Microsoft Framework and taking inventory of the internal types and members ... there are quite a few. In fact, in the Windows.Forms assembly there are entire modules that have internal types. How Microsoft tests these is their problem but by no means should they be public. Hopefully their test coverage of internal members and types are a side-effect of externally visible members. Also there are other (less important yet important) things to consider outside design ... there may be a people factor involved. Perhaps I want to improve the visibility of unit tests and a means of emphasis of their importance to a staff that is NOT exactly "test infected." Placement of your tests outside the assembly is fine ... for you. You have assessed the tradeoffs on design, etc and have made a decision as have I. What we are left with is a preference. Regards, Stephen -----Original Message----- From: Erich Eichinger [mailto:E.E...@di...] Sent: Wednesday, September 12, 2007 11:53 AM To: Trudel, Stephen; Mark Pollack; Bruno Baia; springnet-developer Subject: RE: [Springnet-developer] Object creation invokingprotectedconstructors? Hi Stephen, agreed that these circumstances exist and I'm pretty sure that everyone is already more or less convinced, that Spring.NET should support them. Means +1 from me for supporting non-public classes and their members (ctor, method, props). What I was trying to say - and I think Mark as well - is, that it drives your design positively if you place your tests in another assembly, because the need for testing internal classes is more an exception than the usual case. Sometimes you find, that you can't test a class because it is internal - which in general (at least to my experience) is a sign to rethink the design or it is an implementation detail. I remember when starting TDD myself, I placed my tests into the same assemblies for the same reasons you described here. The danger you run into when doing this is that you might easily overlook that you are testing implementation details - which makes it hard to change these details later. A lot of tests later I'm convinced that it is an important instrument for improving the API of my classes to place the tests into their own assembly. cheers, Erich ________________________________ From: Trudel, Stephen [mailto:ste...@ba...] Sent: Wednesday, September 12, 2007 2:50 PM To: Mark Pollack; Erich Eichinger; Bruno Baia; springnet-developer Subject: RE: [Springnet-developer] Object creation invokingprotectedconstructors? Mark, As we all know, the whole point is to allow separation the abstraction from its implementation so the two can vary independently (GoF, Bridge Pattern) ... that is great and I am glad Spring helps to apply this pattern declaratively. The question is one of scope. By design do we want client code outside the physical assembly ("external code") to inject implementations? The answer to this question is rarely yes in my opinion so I agree with you. - Maybe allowing external code to inject would do more harm than good. Rare? Yes. - Maybe it just does not make sense for external code to provide the implementation but for testing purposes the developer want to swap in a separate mock implementation. - etc I think a more important question is do these circumstances exist? I think they do. I did not interpret your email as aggressive at all with regard to unit test placement. Regards, Stephen ________________________________ From: Mark Pollack [mailto:mpo...@in...] Sent: Tuesday, September 11, 2007 6:23 PM To: Trudel, Stephen; 'Erich Eichinger'; 'Bruno Baia'; 'springnet-developer' Subject: RE: [Springnet-developer] Object creation invokingprotectedconstructors? Hi Stephen, Yup, at your own risk pretty much summarizes what I think is going on here. I'd hope that this is a rare case since if one was developing an API for public consumption one would assume it has enough functionality marked as public so that it is amenable to instantiate configuration via its public API, either via 'new' or via dedicated factory objects. I also see your point with environments putting constraints on where test cases reside, I wasn't trying to imply a 'best way' as usually the best way is dependent on many many things, such as how you migrate to PROD, shipping policies...sometimes it is just the whim of a point-haired manager J Anyway, I realize my email might have been a bit terse/aggressive, that wasn't my intention, just trying to sneak in a few emails on my vacation. Cheers, Mark From: Trudel, Stephen [mailto:ste...@ba...] Sent: Tuesday, September 11, 2007 2:52 PM To: Mark Pollack; Erich Eichinger; Bruno Baia; springnet-developer Subject: RE: [Springnet-developer] Object creation invokingprotectedconstructors? Mark, I think most of us agree if developers are invoking non-public members on classes they did not create then they are doing so at their own risk. I think there is an argument that perhaps is being overlooked or I did not read everyone posts carefully. If so I apologize. Consider if you are the class designer, your classes have internal members by design, and today you are NOT using Spring. Tomorrow you decide to use Spring and you now have to change your class design. That seems intrusive. I really like your idea for top level attribute to the objects element ... its explicit. Whether the tests can shipped to production or not depends in part on if you promote source or promote binaries through the promotion pipeline. Our releases (QA, UAT, PROD) are done by another group who for audit reasons CANNOT promote binaries (rule only applies to PROD but we follow the same process regardless). This group must build the application from version control. Based on certain conditions (e.g. non-DEV build) we can turn on or off a compilation switch resulting in our unit tests being excluded from a release. There are other approaches to achieve this exclusion as well. Clearly there are tradeoffs to consider. In my experience no one has convinced me that tests residing in the same assembly is a bad practice. Regards, Stephen ________________________________ From: Mark Pollack [mailto:mpo...@in...] Sent: Tuesday, September 11, 2007 1:42 PM To: Trudel, Stephen; 'Erich Eichinger'; 'Bruno Baia'; 'springnet-developer' Subject: RE: [Springnet-developer] Object creation invokingprotectedconstructors? Hi, I can see the +'s of allowing it, i.e. if a developer *really* needs to go under the covers to get something to work, we shouldn't get in the way, and the -'s of doing it, you subvert the intention of the original designer of the class. How about we provide a top level attribute to the <objects> element that allow for one to call protected constructors and appropriate API changes to the context classes. This way, the default is not to allow it, but if you need it, the requirements is made explicitly and the contract is global. It also keeps the solutions simple, i.e. not per object functionality. An additional question, should one also allow calling of protected properties, private ctor/properties? Probably something along the lines of xor'ing of binding properties would make sense if we want to go down that path. I'd guess that in some cases, people don't like having the test .dll dependencies within the 'production' assembly that gets shiped to clients, so tests are placed in a separate assembly. Cheers, Mark From: spr...@li... [mailto:spr...@li...] On Behalf Of Trudel, Stephen Sent: Tuesday, September 11, 2007 8:19 AM To: Erich Eichinger; Bruno Baia; springnet-developer Subject: Re: [Springnet-developer] Object creation invokingprotectedconstructors? The goals of TDD can be achieved as easily when the tests are inside the assembly. ________________________________ From: spr...@li... [mailto:spr...@li...] On Behalf Of Erich Eichinger Sent: Tuesday, September 11, 2007 8:10 AM To: Bruno Baia; springnet-developer Subject: Re: [Springnet-developer] Object creation invokingprotectedconstructors? Hi, Personally I'm also not a big fan of making everything internal. Even more, I think that writing tests for my classes *outside* the assembly is a really good way for driving the design. I *want* my tests to influence the design (that's what TDD is all about I guess). Although I think Spring should somewhat enforce what we think are best practices, the world is not always ideal and there are situations where I wished that Spring supported accessing non-public code. -Erich ________________________________ From: spr...@li... [mailto:spr...@li...] On Behalf Of Bruno Baia Sent: Tuesday, September 11, 2007 2:02 PM To: Erich Eichinger Cc: springnet-developer Subject: Re: [Springnet-developer] Object creation invokingprotectedconstructors? Hi, To do that, Microsoft uses their new feature in .NET 2.0 : the InternalsVisibleTo attribute to specify the assembly to which all nonpublic types are to be made visible. (Take a look to System.ServiceModel.dll for an example.) I've also read somewhere MS uses reflection to testes non visible classes too. Anyway, I'm really not a fan of that InternalsVisibleToAttribute because everything becomes internal now... Bruno 2007/9/11, Erich Eichinger <E.E...@di...>: Hi Stepen, playing the "advocatus diaboli" now: How do you write tests for this class then? If your design does not allow for instantiating the class, why should Spring be allowed to? -Erich ________________________________ From: spr...@li... [mailto:spr...@li...] On Behalf Of Trudel, Stephen Sent: Tuesday, September 11, 2007 1:40 PM To: Erich Eichinger; springnet-developer Subject: Re: [Springnet-developer] Object creation invokingprotected constructors? Related question ... does Spring.Net support object construction for objects with internal constructors? If one does not want the instantiation of an object to be allowed outside the scope of a module for purposes of conceptual integrity or otherwise then Spring.Net should support its construction in my opinion ... seem somewhat awkward when class design is influenced by a framework ... ________________________________ From: spr...@li... [mailto:spr...@li...] On Behalf Of Erich Eichinger Sent: Sunday, September 09, 2007 6:36 AM To: springnet-developer Subject: [Springnet-developer] Object creation invoking protected constructors? Steinar on the forum asked this here: http://forum.springframework.net/showthread.php?t=3448 I'd like to revisit the design decision to not allow accessing non-public types/constructors/methods/properties and hear your opinions on this. I recently ran into this issue myself when trying to provide a DI capable wrapper for "System.Web.UI.SimpleHandlerFactory" from System.Web assembly. This type is internal and can't be instantiated using Spring which required to implement a (non-trivial) workaround. The easy way would be to remove the restriction to public types. I know of opinions out there to don't enforce any restrictions within the framework. Developers should know what they are doing and if someone wants to instantiate a non-public type, let him do it at his own risk. Other opinions? cheers, Erich ------------------------------------------------------------------------ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Springnet-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springnet-developer |
|
From: Erich E. <eei...@gm...> - 2007-09-14 09:06:11
|
Hi Stephen, God knows how we are suffering from MS framework folks making everything internal. It made enabling Spring.Web DI and others a nightmare and took me weeks of browsing the framework assemblies using reflector. It's also the major reason, why there is no production-ready WinForms DI available yet. Thanks for taking the time to elaborate your position. It's very interesting for me to understand your reasoning. In fact I struggled with this problem for a long time until I made my decision - one of my reasons to place tests in a different assembly was to avoid references to nunit.framework (& co) in my production assemblies. I never had the idea of placing the tests inside a preprocessor switch. Nevertheless I won't revert my decision. Especially when looking at the .net framework bcl, I'm pretty sure that their design would have been much better and more modular if they wrote their tests in external assemblies. cheers, Erich > -----Original Message----- > From: spr...@li... > [mailto:spr...@li...] On > Behalf Of Trudel, Stephen > Sent: Donnerstag, 13. September 2007 15:04 > To: Erich Eichinger; Mark Pollack; Bruno Baia; springnet-developer > Subject: Re: [Springnet-developer]Object creation > invokingprotectedconstructors? > > Erich, > > I believe Mark was referring to the overhead of excluding the > tests at a > later time. > > There are also dangers to having the tests outside the assembly. I > often look at open source libraries and wonder why some abstractions > which in fact support internal details are made public. Is it so they > can be tested? A person using the API has to understand what > all these > types are for and how they fit together. That can be quite > overwhelming. Do we want to muddy the waters with types and members > that should be internal? Not if usability and productivity are of > utmost importance. I recommend taking a peek inside Reflector for the > Microsoft Framework and taking inventory of the internal types and > members ... there are quite a few. In fact, in the Windows.Forms > assembly there are entire modules that have internal types. How > Microsoft tests these is their problem but by no means should they be > public. Hopefully their test coverage of internal members > and types are > a side-effect of externally visible members. > > Also there are other (less important yet important) things to consider > outside design ... there may be a people factor involved. Perhaps I > want to improve the visibility of unit tests and a means of > emphasis of > their importance to a staff that is NOT exactly "test infected." > > Placement of your tests outside the assembly is fine ... for you. You > have assessed the tradeoffs on design, etc and have made a decision as > have I. What we are left with is a preference. > > Regards, > Stephen > > > -----Original Message----- > From: Erich Eichinger [mailto:E.E...@di...] > Sent: Wednesday, September 12, 2007 11:53 AM > To: Trudel, Stephen; Mark Pollack; Bruno Baia; springnet-developer > Subject: RE: [Springnet-developer] Object creation > invokingprotectedconstructors? > > > Hi Stephen, > > agreed that these circumstances exist and I'm pretty sure > that everyone > is already more or less convinced, that Spring.NET should > support them. > Means +1 from me for supporting non-public classes and their members > (ctor, method, props). > > What I was trying to say - and I think Mark as well - is, > that it drives > your design positively if you place your tests in another assembly, > because the need for testing internal classes is more an > exception than > the usual case. Sometimes you find, that you can't test a > class because > it is internal - which in general (at least to my experience) > is a sign > to rethink the design or it is an implementation detail. I > remember when > starting TDD myself, I placed my tests into the same > assemblies for the > same reasons you described here. The danger you run into when > doing this > is that you might easily overlook that you are testing implementation > details - which makes it hard to change these details later. A lot of > tests later I'm convinced that it is an important instrument for > improving the API of my classes to place the tests into their own > assembly. > > cheers, > Erich > > > ________________________________ > > From: Trudel, Stephen [mailto:ste...@ba...] > Sent: Wednesday, September 12, 2007 2:50 PM > To: Mark Pollack; Erich Eichinger; Bruno Baia; > springnet-developer > Subject: RE: [Springnet-developer] Object creation > invokingprotectedconstructors? > > > Mark, > > As we all know, the whole point is to allow separation the > abstraction from its implementation so the two can vary independently > (GoF, Bridge Pattern) ... that is great and I am glad Spring helps to > apply this pattern declaratively. > > The question is one of scope. By design do we want client code > outside the physical assembly ("external code") to inject > implementations? The answer to this question is rarely yes in my > opinion so I agree with you. > > - Maybe allowing external code to inject would do more harm than > good. Rare? Yes. > - Maybe it just does not make sense for external code to provide > the implementation but for testing purposes the developer want to swap > in a separate mock implementation. > - etc > > I think a more important question is do these circumstances > exist? I think they do. > > I did not interpret your email as aggressive at all with regard > to unit test placement. > > Regards, > Stephen > > ________________________________ > > From: Mark Pollack [mailto:mpo...@in...] > Sent: Tuesday, September 11, 2007 6:23 PM > To: Trudel, Stephen; 'Erich Eichinger'; 'Bruno Baia'; > 'springnet-developer' > Subject: RE: [Springnet-developer] Object creation > invokingprotectedconstructors? > > > > Hi Stephen, > > > > Yup, at your own risk pretty much summarizes what I think is > going on here. I'd hope that this is a rare case since if one was > developing an API for public consumption one would assume it > has enough > functionality marked as public so that it is amenable to instantiate > configuration via its public API, either via 'new' or via dedicated > factory objects. I also see your point with environments putting > constraints on where test cases reside, I wasn't trying to > imply a 'best > way' as usually the best way is dependent on many many things, such as > how you migrate to PROD, shipping policies...sometimes it is just the > whim of a point-haired manager J Anyway, I realize my email > might have > been a bit terse/aggressive, that wasn't my intention, just trying to > sneak in a few emails on my vacation. > > > > Cheers, > > Mark > > > > > > > > > > > > > > From: Trudel, Stephen [mailto:ste...@ba...] > Sent: Tuesday, September 11, 2007 2:52 PM > To: Mark Pollack; Erich Eichinger; Bruno Baia; > springnet-developer > Subject: RE: [Springnet-developer] Object creation > invokingprotectedconstructors? > > > > Mark, > > > > I think most of us agree if developers are invoking non-public > members on classes they did not create then they are doing so at their > own risk. I think there is an argument that perhaps is being > overlooked > or I did not read everyone posts carefully. If so I apologize. > Consider if you are the class designer, your classes have internal > members by design, and today you are NOT using Spring. Tomorrow you > decide to use Spring and you now have to change your class > design. That > seems intrusive. > > > > I really like your idea for top level attribute to the objects > element ... its explicit. > > > > Whether the tests can shipped to production or not depends in > part on if you promote source or promote binaries through the > promotion > pipeline. Our releases (QA, UAT, PROD) are done by another group who > for audit reasons CANNOT promote binaries (rule only applies > to PROD but > we follow the same process regardless). This group must build the > application from version control. Based on certain conditions (e.g. > non-DEV build) we can turn on or off a compilation switch resulting in > our unit tests being excluded from a release. There are other > approaches to achieve this exclusion as well. Clearly there are > tradeoffs to consider. In my experience no one has convinced me that > tests residing in the same assembly is a bad practice. > > > > Regards, > > Stephen > > > > ________________________________ > > From: Mark Pollack [mailto:mpo...@in...] > Sent: Tuesday, September 11, 2007 1:42 PM > To: Trudel, Stephen; 'Erich Eichinger'; 'Bruno Baia'; > 'springnet-developer' > Subject: RE: [Springnet-developer] Object creation > invokingprotectedconstructors? > > Hi, > > > > I can see the +'s of allowing it, i.e. if a developer *really* > needs to go under the covers to get something to work, we > shouldn't get > in the way, and the -'s of doing it, you subvert the intention of the > original designer of the class. How about we provide a top level > attribute to the <objects> element that allow for one to call > protected > constructors and appropriate API changes to the context classes. This > way, the default is not to allow it, but if you need it, the > requirements is made explicitly and the contract is global. It also > keeps the solutions simple, i.e. not per object functionality. > > > > An additional question, should one also allow calling of > protected properties, private ctor/properties? Probably > something along > the lines of xor'ing of binding properties would make sense if we want > to go down that path. > > > > I'd guess that in some cases, people don't like having the test > .dll dependencies within the 'production' assembly that gets shiped to > clients, so tests are placed in a separate assembly. > > > > Cheers, > > Mark > > > > > > > > > > From: spr...@li... > [mailto:spr...@li...] On > Behalf Of > Trudel, Stephen > Sent: Tuesday, September 11, 2007 8:19 AM > To: Erich Eichinger; Bruno Baia; springnet-developer > Subject: Re: [Springnet-developer] Object creation > invokingprotectedconstructors? > > > > The goals of TDD can be achieved as easily when the tests are > inside the assembly. > > > > ________________________________ > > From: spr...@li... > [mailto:spr...@li...] On > Behalf Of > Erich Eichinger > Sent: Tuesday, September 11, 2007 8:10 AM > To: Bruno Baia; springnet-developer > Subject: Re: [Springnet-developer] Object creation > invokingprotectedconstructors? > > Hi, > > > > Personally I'm also not a big fan of making everything internal. > Even more, I think that writing tests for my classes *outside* the > assembly is a really good way for driving the design. I > *want* my tests > to influence the design (that's what TDD is all about I guess). > > > > Although I think Spring should somewhat enforce what we think > are best practices, the world is not always ideal and there are > situations where I wished that Spring supported accessing non-public > code. > > > > -Erich > > > > > > > > ________________________________ > > From: > spr...@li... > [mailto:spr...@li...] On > Behalf Of > Bruno Baia > Sent: Tuesday, September 11, 2007 2:02 PM > To: Erich Eichinger > Cc: springnet-developer > Subject: Re: [Springnet-developer] Object creation > invokingprotectedconstructors? > > Hi, > > > > To do that, Microsoft uses their new feature in .NET 2.0 > : the InternalsVisibleTo attribute to specify the assembly to > which all > nonpublic types are to be made visible. (Take a look to > System.ServiceModel.dll for an example.) > > I've also read somewhere MS uses reflection to testes > non visible classes too. > > > > Anyway, I'm really not a fan of that > InternalsVisibleToAttribute because everything becomes internal now... > > > > > > Bruno > > > > 2007/9/11, Erich Eichinger <E.E...@di...>: > > > Hi Stepen, > > > > playing the "advocatus diaboli" now: How do you write > tests for this class then? If your design does not allow for > instantiating the class, why should Spring be allowed to? > > > > -Erich > > > > ________________________________ > > From: > spr...@li... > [mailto:spr...@li...] On > Behalf Of > Trudel, Stephen > Sent: Tuesday, September 11, 2007 1:40 PM > To: Erich Eichinger; springnet-developer > Subject: Re: [Springnet-developer] Object > creation invokingprotected constructors? > > > > Related question ... does Spring.Net support > object construction for objects with internal constructors? > If one does > not want the instantiation of an object to be allowed outside > the scope > of a module for purposes of conceptual integrity or otherwise then > Spring.Net should support its construction in my opinion ... seem > somewhat awkward when class design is influenced by a framework ... > > > > > ________________________________ > > From: > spr...@li... > [mailto:spr...@li...] On > Behalf Of > Erich Eichinger > Sent: Sunday, September 09, 2007 6:36 AM > To: springnet-developer > Subject: [Springnet-developer] Object creation > invoking protected constructors? > > > > Steinar on the forum asked this here: > http://forum.springframework.net/showthread.php?t=3448 > > > > I'd like to revisit the design decision to not > allow accessing non-public types/constructors/methods/properties and > hear your opinions on this. > > > > I recently ran into this issue myself when > trying to provide a DI capable wrapper for > "System.Web.UI.SimpleHandlerFactory" from System.Web > assembly. This type > is internal and can't be instantiated using Spring which required to > implement a (non-trivial) workaround. The easy way would be to remove > the restriction to public types. > > > > I know of opinions out there to don't enforce > any restrictions within the framework. Developers should know > what they > are doing and if someone wants to instantiate a non-public > type, let him > do it at his own risk. > > > > Other opinions? > > > > cheers, > > Erich > > > > > > -------------------------------------------------------------- > ---------- > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Springnet-developer mailing list > Spr...@li... > > https://lists.sourceforge.net/lists/listinfo/springnet-developer > > > > > -------------------------------------------------------------- > ----------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Springnet-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springnet-developer |
|
From: Trudel, S. <ste...@ba...> - 2007-09-14 14:45:31
|
Erich, I think many (if not most) times the author of the software has a biased opinion as to its simplicity/usability. Why? They understand the abstractions naturally because they wrote them ... they understand what those abstractions are responsible for, how those abstractions behave, where those abstractions fit, what abstractions are related to each other, when the abstractions are created, when the abstractions are used, how those abstractions are configured, etc etc etc. That can be a lot of information to consume for consumers. With that said, I think there is sound rationale to keep many things internal especially on a commercial framework (more so than a line-of-business application or perhaps even an open-source framework). With respect to Microsoft, what they have done with the .Net Framework is very intentional by design. A book that talks specifically to this is Framework Design Guidelines by Brad Abrams ... you may have this one or are familiar with it. They specifically say they try to reduce the number of externally abstractions (visible or not). After all, they are trying to create a framework of all things for all communities (C++, Java, VB, etc, etc, etc). Microsoft does usability studies on their APIs to test how much suffering they are causing. I think a key question is what type of suffering are they concerned with? Perhaps the suffering you are experiencing could be different based on what you are trying to do. Perhaps you have to learn internal details of types that Microsoft probably did not have any intention of you learning. I am not sure. What I am confident of is their intent. Regards, Stephen -----Original Message----- From: Erich Eichinger [mailto:eei...@gm...] Sent: Friday, September 14, 2007 5:06 AM To: Trudel, Stephen; 'Mark Pollack'; 'Bruno Baia'; 'springnet-developer' Subject: RE: [Springnet-developer]Object creation invokingprotectedconstructors? Hi Stephen, God knows how we are suffering from MS framework folks making everything internal. It made enabling Spring.Web DI and others a nightmare and took me weeks of browsing the framework assemblies using reflector. It's also the major reason, why there is no production-ready WinForms DI available yet. Thanks for taking the time to elaborate your position. It's very interesting for me to understand your reasoning. In fact I struggled with this problem for a long time until I made my decision - one of my reasons to place tests in a different assembly was to avoid references to nunit.framework (& co) in my production assemblies. I never had the idea of placing the tests inside a preprocessor switch. Nevertheless I won't revert my decision. Especially when looking at the .net framework bcl, I'm pretty sure that their design would have been much better and more modular if they wrote their tests in external assemblies. cheers, Erich > -----Original Message----- > From: spr...@li... > [mailto:spr...@li...] On > Behalf Of Trudel, Stephen > Sent: Donnerstag, 13. September 2007 15:04 > To: Erich Eichinger; Mark Pollack; Bruno Baia; springnet-developer > Subject: Re: [Springnet-developer]Object creation > invokingprotectedconstructors? > > Erich, > > I believe Mark was referring to the overhead of excluding the > tests at a > later time. > > There are also dangers to having the tests outside the assembly. I > often look at open source libraries and wonder why some abstractions > which in fact support internal details are made public. Is it so they > can be tested? A person using the API has to understand what > all these > types are for and how they fit together. That can be quite > overwhelming. Do we want to muddy the waters with types and members > that should be internal? Not if usability and productivity are of > utmost importance. I recommend taking a peek inside Reflector for the > Microsoft Framework and taking inventory of the internal types and > members ... there are quite a few. In fact, in the Windows.Forms > assembly there are entire modules that have internal types. How > Microsoft tests these is their problem but by no means should they be > public. Hopefully their test coverage of internal members > and types are > a side-effect of externally visible members. > > Also there are other (less important yet important) things to consider > outside design ... there may be a people factor involved. Perhaps I > want to improve the visibility of unit tests and a means of > emphasis of > their importance to a staff that is NOT exactly "test infected." > > Placement of your tests outside the assembly is fine ... for you. You > have assessed the tradeoffs on design, etc and have made a decision as > have I. What we are left with is a preference. > > Regards, > Stephen > > > -----Original Message----- > From: Erich Eichinger [mailto:E.E...@di...] > Sent: Wednesday, September 12, 2007 11:53 AM > To: Trudel, Stephen; Mark Pollack; Bruno Baia; springnet-developer > Subject: RE: [Springnet-developer] Object creation > invokingprotectedconstructors? > > > Hi Stephen, > > agreed that these circumstances exist and I'm pretty sure > that everyone > is already more or less convinced, that Spring.NET should > support them. > Means +1 from me for supporting non-public classes and their members > (ctor, method, props). > > What I was trying to say - and I think Mark as well - is, > that it drives > your design positively if you place your tests in another assembly, > because the need for testing internal classes is more an > exception than > the usual case. Sometimes you find, that you can't test a > class because > it is internal - which in general (at least to my experience) > is a sign > to rethink the design or it is an implementation detail. I > remember when > starting TDD myself, I placed my tests into the same > assemblies for the > same reasons you described here. The danger you run into when > doing this > is that you might easily overlook that you are testing implementation > details - which makes it hard to change these details later. A lot of > tests later I'm convinced that it is an important instrument for > improving the API of my classes to place the tests into their own > assembly. > > cheers, > Erich > > > ________________________________ > > From: Trudel, Stephen [mailto:ste...@ba...] > Sent: Wednesday, September 12, 2007 2:50 PM > To: Mark Pollack; Erich Eichinger; Bruno Baia; > springnet-developer > Subject: RE: [Springnet-developer] Object creation > invokingprotectedconstructors? > > > Mark, > > As we all know, the whole point is to allow separation the > abstraction from its implementation so the two can vary independently > (GoF, Bridge Pattern) ... that is great and I am glad Spring helps to > apply this pattern declaratively. > > The question is one of scope. By design do we want client code > outside the physical assembly ("external code") to inject > implementations? The answer to this question is rarely yes in my > opinion so I agree with you. > > - Maybe allowing external code to inject would do more harm than > good. Rare? Yes. > - Maybe it just does not make sense for external code to provide > the implementation but for testing purposes the developer want to swap > in a separate mock implementation. > - etc > > I think a more important question is do these circumstances > exist? I think they do. > > I did not interpret your email as aggressive at all with regard > to unit test placement. > > Regards, > Stephen > > ________________________________ > > From: Mark Pollack [mailto:mpo...@in...] > Sent: Tuesday, September 11, 2007 6:23 PM > To: Trudel, Stephen; 'Erich Eichinger'; 'Bruno Baia'; > 'springnet-developer' > Subject: RE: [Springnet-developer] Object creation > invokingprotectedconstructors? > > > > Hi Stephen, > > > > Yup, at your own risk pretty much summarizes what I think is > going on here. I'd hope that this is a rare case since if one was > developing an API for public consumption one would assume it > has enough > functionality marked as public so that it is amenable to instantiate > configuration via its public API, either via 'new' or via dedicated > factory objects. I also see your point with environments putting > constraints on where test cases reside, I wasn't trying to > imply a 'best > way' as usually the best way is dependent on many many things, such as > how you migrate to PROD, shipping policies...sometimes it is just the > whim of a point-haired manager J Anyway, I realize my email > might have > been a bit terse/aggressive, that wasn't my intention, just trying to > sneak in a few emails on my vacation. > > > > Cheers, > > Mark > > > > > > > > > > > > > > From: Trudel, Stephen [mailto:ste...@ba...] > Sent: Tuesday, September 11, 2007 2:52 PM > To: Mark Pollack; Erich Eichinger; Bruno Baia; > springnet-developer > Subject: RE: [Springnet-developer] Object creation > invokingprotectedconstructors? > > > > Mark, > > > > I think most of us agree if developers are invoking non-public > members on classes they did not create then they are doing so at their > own risk. I think there is an argument that perhaps is being > overlooked > or I did not read everyone posts carefully. If so I apologize. > Consider if you are the class designer, your classes have internal > members by design, and today you are NOT using Spring. Tomorrow you > decide to use Spring and you now have to change your class > design. That > seems intrusive. > > > > I really like your idea for top level attribute to the objects > element ... its explicit. > > > > Whether the tests can shipped to production or not depends in > part on if you promote source or promote binaries through the > promotion > pipeline. Our releases (QA, UAT, PROD) are done by another group who > for audit reasons CANNOT promote binaries (rule only applies > to PROD but > we follow the same process regardless). This group must build the > application from version control. Based on certain conditions (e.g. > non-DEV build) we can turn on or off a compilation switch resulting in > our unit tests being excluded from a release. There are other > approaches to achieve this exclusion as well. Clearly there are > tradeoffs to consider. In my experience no one has convinced me that > tests residing in the same assembly is a bad practice. > > > > Regards, > > Stephen > > > > ________________________________ > > From: Mark Pollack [mailto:mpo...@in...] > Sent: Tuesday, September 11, 2007 1:42 PM > To: Trudel, Stephen; 'Erich Eichinger'; 'Bruno Baia'; > 'springnet-developer' > Subject: RE: [Springnet-developer] Object creation > invokingprotectedconstructors? > > Hi, > > > > I can see the +'s of allowing it, i.e. if a developer *really* > needs to go under the covers to get something to work, we > shouldn't get > in the way, and the -'s of doing it, you subvert the intention of the > original designer of the class. How about we provide a top level > attribute to the <objects> element that allow for one to call > protected > constructors and appropriate API changes to the context classes. This > way, the default is not to allow it, but if you need it, the > requirements is made explicitly and the contract is global. It also > keeps the solutions simple, i.e. not per object functionality. > > > > An additional question, should one also allow calling of > protected properties, private ctor/properties? Probably > something along > the lines of xor'ing of binding properties would make sense if we want > to go down that path. > > > > I'd guess that in some cases, people don't like having the test > .dll dependencies within the 'production' assembly that gets shiped to > clients, so tests are placed in a separate assembly. > > > > Cheers, > > Mark > > > > > > > > > > From: spr...@li... > [mailto:spr...@li...] On > Behalf Of > Trudel, Stephen > Sent: Tuesday, September 11, 2007 8:19 AM > To: Erich Eichinger; Bruno Baia; springnet-developer > Subject: Re: [Springnet-developer] Object creation > invokingprotectedconstructors? > > > > The goals of TDD can be achieved as easily when the tests are > inside the assembly. > > > > ________________________________ > > From: spr...@li... > [mailto:spr...@li...] On > Behalf Of > Erich Eichinger > Sent: Tuesday, September 11, 2007 8:10 AM > To: Bruno Baia; springnet-developer > Subject: Re: [Springnet-developer] Object creation > invokingprotectedconstructors? > > Hi, > > > > Personally I'm also not a big fan of making everything internal. > Even more, I think that writing tests for my classes *outside* the > assembly is a really good way for driving the design. I > *want* my tests > to influence the design (that's what TDD is all about I guess). > > > > Although I think Spring should somewhat enforce what we think > are best practices, the world is not always ideal and there are > situations where I wished that Spring supported accessing non-public > code. > > > > -Erich > > > > > > > > ________________________________ > > From: > spr...@li... > [mailto:spr...@li...] On > Behalf Of > Bruno Baia > Sent: Tuesday, September 11, 2007 2:02 PM > To: Erich Eichinger > Cc: springnet-developer > Subject: Re: [Springnet-developer] Object creation > invokingprotectedconstructors? > > Hi, > > > > To do that, Microsoft uses their new feature in .NET 2.0 > : the InternalsVisibleTo attribute to specify the assembly to > which all > nonpublic types are to be made visible. (Take a look to > System.ServiceModel.dll for an example.) > > I've also read somewhere MS uses reflection to testes > non visible classes too. > > > > Anyway, I'm really not a fan of that > InternalsVisibleToAttribute because everything becomes internal now... > > > > > > Bruno > > > > 2007/9/11, Erich Eichinger <E.E...@di...>: > > > Hi Stepen, > > > > playing the "advocatus diaboli" now: How do you write > tests for this class then? If your design does not allow for > instantiating the class, why should Spring be allowed to? > > > > -Erich > > > > ________________________________ > > From: > spr...@li... > [mailto:spr...@li...] On > Behalf Of > Trudel, Stephen > Sent: Tuesday, September 11, 2007 1:40 PM > To: Erich Eichinger; springnet-developer > Subject: Re: [Springnet-developer] Object > creation invokingprotected constructors? > > > > Related question ... does Spring.Net support > object construction for objects with internal constructors? > If one does > not want the instantiation of an object to be allowed outside > the scope > of a module for purposes of conceptual integrity or otherwise then > Spring.Net should support its construction in my opinion ... seem > somewhat awkward when class design is influenced by a framework ... > > > > > ________________________________ > > From: > spr...@li... > [mailto:spr...@li...] On > Behalf Of > Erich Eichinger > Sent: Sunday, September 09, 2007 6:36 AM > To: springnet-developer > Subject: [Springnet-developer] Object creation > invoking protected constructors? > > > > Steinar on the forum asked this here: > http://forum.springframework.net/showthread.php?t=3448 > > > > I'd like to revisit the design decision to not > allow accessing non-public types/constructors/methods/properties and > hear your opinions on this. > > > > I recently ran into this issue myself when > trying to provide a DI capable wrapper for > "System.Web.UI.SimpleHandlerFactory" from System.Web > assembly. This type > is internal and can't be instantiated using Spring which required to > implement a (non-trivial) workaround. The easy way would be to remove > the restriction to public types. > > > > I know of opinions out there to don't enforce > any restrictions within the framework. Developers should know > what they > are doing and if someone wants to instantiate a non-public > type, let him > do it at his own risk. > > > > Other opinions? > > > > cheers, > > Erich > > > > > > -------------------------------------------------------------- > ---------- > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Springnet-developer mailing list > Spr...@li... > > https://lists.sourceforge.net/lists/listinfo/springnet-developer > > > > > -------------------------------------------------------------- > ----------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Springnet-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springnet-developer |
|
From: Trudel, S. <ste...@ba...> - 2007-09-11 11:50:25
|
I prefer to have my tests are embedded in the module (i.e. there is a UnitTest sub-module in every module). I don't want the fact that my unit tests are outside the project to influence class design either. I use a compilation switch to exclude them. ________________________________ From: Erich Eichinger [mailto:E.E...@di...] Sent: Tuesday, September 11, 2007 7:44 AM To: Trudel, Stephen; springnet-developer Subject: RE: [Springnet-developer] Object creation invokingprotected constructors? Hi Stepen, playing the "advocatus diaboli" now: How do you write tests for this class then? If your design does not allow for instantiating the class, why should Spring be allowed to? -Erich ________________________________ From: spr...@li... [mailto:spr...@li...] On Behalf Of Trudel, Stephen Sent: Tuesday, September 11, 2007 1:40 PM To: Erich Eichinger; springnet-developer Subject: Re: [Springnet-developer] Object creation invokingprotected constructors? Related question ... does Spring.Net support object construction for objects with internal constructors? If one does not want the instantiation of an object to be allowed outside the scope of a module for purposes of conceptual integrity or otherwise then Spring.Net should support its construction in my opinion ... seem somewhat awkward when class design is influenced by a framework ... ________________________________ From: spr...@li... [mailto:spr...@li...] On Behalf Of Erich Eichinger Sent: Sunday, September 09, 2007 6:36 AM To: springnet-developer Subject: [Springnet-developer] Object creation invoking protected constructors? Steinar on the forum asked this here: http://forum.springframework.net/showthread.php?t=3448 I'd like to revisit the design decision to not allow accessing non-public types/constructors/methods/properties and hear your opinions on this. I recently ran into this issue myself when trying to provide a DI capable wrapper for "System.Web.UI.SimpleHandlerFactory" from System.Web assembly. This type is internal and can't be instantiated using Spring which required to implement a (non-trivial) workaround. The easy way would be to remove the restriction to public types. I know of opinions out there to don't enforce any restrictions within the framework. Developers should know what they are doing and if someone wants to instantiate a non-public type, let him do it at his own risk. Other opinions? cheers, Erich |
Thanks for helping keep SourceForge clean.
X