tag:blogger.com,1999:blog-7455565.post7381409221077860894..comments2024-03-28T09:37:29.374-05:00Comments on Scott White's Tech Blog: NUnit Best PracticesAnonymoushttp://www.blogger.com/profile/15458997690728285402noreply@blogger.comBlogger9125tag:blogger.com,1999:blog-7455565.post-51027089441550468852011-04-04T20:02:48.148-05:002011-04-04T20:02:48.148-05:00In all honesty, I really don't like the word &...In all honesty, I really don't like the word "Best Practices" even though I used it, ;-). In retrospect it's not the correct title, 'NUnit recipes' would have been more accurate. Thanks for the feedbackAnonymoushttps://www.blogger.com/profile/15458997690728285402noreply@blogger.comtag:blogger.com,1999:blog-7455565.post-53128115362284217252011-04-01T08:51:40.922-05:002011-04-01T08:51:40.922-05:00@Thomas
Yes, I must agree on your point #7: We ne...@Thomas<br /><br />Yes, I must agree on your point #7: We need to inherit common implementation instead of common usage.Vincenthttps://www.blogger.com/profile/15564167136006890049noreply@blogger.comtag:blogger.com,1999:blog-7455565.post-11655056435099036792008-10-17T18:48:00.000-05:002008-10-17T18:48:00.000-05:00Hi Joe,Some people feel that testing only the publ...Hi Joe,<BR/><BR/>Some people feel that testing only the public interface is a best practice; that generally works well for me.<BR/><BR/>If you prefer, you can use InternalsVisibleTo to allow your unit test assembly to access items with internal visibility.TrueWillhttps://www.blogger.com/profile/06265686844768652228noreply@blogger.comtag:blogger.com,1999:blog-7455565.post-62483713474741797432008-10-17T11:19:00.000-05:002008-10-17T11:19:00.000-05:00"Create a separate assembly for your test fixtures..."Create a separate assembly for your test fixtures"<BR/>Then I can only test public methods from my test code. <BR/>Yikes. <BR/>One of the problems with Microsoft's nUnit-wanna-be implementation is this very fact. And for that very reason our company sticks with nUnit. <BR/>Making something public <I>should</I> take great consideration. Making it public so it can be tested....ouch!Unknownhttps://www.blogger.com/profile/13175838927125715111noreply@blogger.comtag:blogger.com,1999:blog-7455565.post-36384867957687429102008-05-16T00:53:00.000-05:002008-05-16T00:53:00.000-05:00I'm not quite sure whether I understand #5. Genera...I'm not quite sure whether I understand #5. Generally I would say that test-driven developement is about driving the design of the code. This includes the interfaces, and maybe in particular the interfaces. In other words I would start with the tests even for driving out the interface of a class. - Maybe I'm overlooking something. What is the reason that you create the "basic interface" first? What do you mean with "basic interface"?<BR/><BR/>Cheers,<BR/>Manfred.<BR/>---<BR/>Manfred Lange.<BR/>csUnit developer<BR/><A HREF="http://www.csunit.org" REL="nofollow">csUnit Home Page</A><BR/><A HREF="http://agileleadership.blogspot.com" REL="nofollow">On Agile Leadership</A><BR/><A HREF="http://manfredlange.blogspot.com" REL="nofollow">On Dot Net</A>Manfred Langehttps://www.blogger.com/profile/01100831606055102208noreply@blogger.comtag:blogger.com,1999:blog-7455565.post-71316599782862333692008-05-15T02:54:00.000-05:002008-05-15T02:54:00.000-05:00@Scott: I think we are on the same page on #7. Jus...@Scott: I think we are on the same page on #7. Just to clarify, I prefer all my test classes to:<BR/><BR/>[Setup] <BR/>public void Setup() {<BR/>OpenConnection();<BR/>}<BR/><BR/>[TearDown] <BR/>public void Teardown() {<BR/>CloseConnection();<BR/>}<BR/><BR/>However, OpenConnection and CloseConnection could be part of the base class.Thomas Eydehttps://www.blogger.com/profile/16024593954167949907noreply@blogger.comtag:blogger.com,1999:blog-7455565.post-70077094377596692372008-05-12T13:47:00.000-05:002008-05-12T13:47:00.000-05:00Good feedback...on #7I think your approach is vali...Good feedback...<BR/><BR/>on #7<BR/>I think your approach is valid. However I would argue that if you setup you connection in your setup & teardown that it is part of you test since these are executed if you just run one test. Also there's no reason you couldn't expose the setup/teardown methods in your base class<BR/><BR/>on #3<BR/>By having all your bins necessary in a central directory someone can run all your tests whether they are using just one project or even if they are not a programmer at all. You could also have your build server check in the latest build to this location into your source code control as well.<BR/><BR/>ThanksAnonymoushttps://www.blogger.com/profile/15458997690728285402noreply@blogger.comtag:blogger.com,1999:blog-7455565.post-27156363301064025982008-05-12T13:15:00.000-05:002008-05-12T13:15:00.000-05:00For step 2, it's nice to have a global library dir...For step 2, it's nice to have a global library directory in source control with the NUnit binaries in there (Pragmatic Unit Testing recommends something similar).<BR/><BR/>Step 3 I don't quite get; we tend to create a separate project in the same solution for the unit test project. It references the main project using a project reference. There's no need for a post-build event.<BR/><BR/>Thanks,<BR/><A HREF="http://truewill.net/myblog/index.php" REL="nofollow">Bill Sorensen</A>TrueWillhttps://www.blogger.com/profile/06265686844768652228noreply@blogger.comtag:blogger.com,1999:blog-7455565.post-8224548710314271122008-05-10T18:00:00.000-05:002008-05-10T18:00:00.000-05:00I slightly disagree with your point #7: I think it...I slightly disagree with your point #7: I think it's a good thing to let my test classes expose everything it does. I consider base setups and teardowns a code smell.<BR/><BR/>In other words, when it comes to test classes, it's ok to inherit common implementation, but not common usage. Whenever my test class opens a database connection, I want to see it in the test - not in the base.Thomas Eydehttps://www.blogger.com/profile/16024593954167949907noreply@blogger.com