Let's play a new game. One in which I make a detailed post that tries to make absolutely little sense to any of you and you provide a detailed response that will make absolutely little sense to me.
I am still in technical debt based on the design choices I made based on my lack of fluency with scons, python, and ASP.Net. The initial build system limped along with the aid of an attendant. What I essentially did was throw her into an assisted living community. But she's still wetting herself, going into cardiac arrest, and refusing to take her medication. So I've gone the 6 million dollar man route and rewrote the core build structure to allow for a number of needed features like: exception handling; debug logging; logging system events and e-mailing on error/critical failures; and unit tests.
On the subject of unit tests. I understand the idea behind sealed/final classes but I really never had any strong feelings for them. Until I came upon the challenge of actually testing one. I never even thought of sub-classing one in this world of design patterns clamoring for encapsulation (which I agree with completely in most every cases). So I throw it in another class and wire up the methods and properties I need to fake out and that is when I learn that one of the objects that the class returns is also another set of sealed/final/abstract classes that I can't simply fake without encapsulating again or running them through some mock factory. How far down the rathole goes...
The other problem is that it fails to address the fact that I can't call the method directly. So reflection takes center stage and I can call upon the methods that were not intended for me to call but then I find that I need to manufacture the actual test object.
Fuck it.
However, from the above experience, in the desperation brought on by this moment I found some amazing websites related to the problem. Particularly two libraries: Duck Typing and Rhino Mocks. Besides their usefulness it's fun to pepper your conversations with these words. I will admit that I would have preferred a different mock system but I am currently not living in a world of .NET 3.5.
Coupling these tools with those that generate static analysis and dynamic code analysis (McCabe, though I am on the lookout for a good free one) makes me realize that there is absolute overabundance of tools and libraries that I have yet to find and employ in my everyday development.
I am still in technical debt based on the design choices I made based on my lack of fluency with scons, python, and ASP.Net. The initial build system limped along with the aid of an attendant. What I essentially did was throw her into an assisted living community. But she's still wetting herself, going into cardiac arrest, and refusing to take her medication. So I've gone the 6 million dollar man route and rewrote the core build structure to allow for a number of needed features like: exception handling; debug logging; logging system events and e-mailing on error/critical failures; and unit tests.
On the subject of unit tests. I understand the idea behind sealed/final classes but I really never had any strong feelings for them. Until I came upon the challenge of actually testing one. I never even thought of sub-classing one in this world of design patterns clamoring for encapsulation (which I agree with completely in most every cases). So I throw it in another class and wire up the methods and properties I need to fake out and that is when I learn that one of the objects that the class returns is also another set of sealed/final/abstract classes that I can't simply fake without encapsulating again or running them through some mock factory. How far down the rathole goes...
The other problem is that it fails to address the fact that I can't call the method directly. So reflection takes center stage and I can call upon the methods that were not intended for me to call but then I find that I need to manufacture the actual test object.
Fuck it.
However, from the above experience, in the desperation brought on by this moment I found some amazing websites related to the problem. Particularly two libraries: Duck Typing and Rhino Mocks. Besides their usefulness it's fun to pepper your conversations with these words. I will admit that I would have preferred a different mock system but I am currently not living in a world of .NET 3.5.
Coupling these tools with those that generate static analysis and dynamic code analysis (McCabe, though I am on the lookout for a good free one) makes me realize that there is absolute overabundance of tools and libraries that I have yet to find and employ in my everyday development.
bird:
hi 