tag:blogger.com,1999:blog-1625656052645899431.post5807475543449201415..comments2024-03-08T01:31:16.071-08:00Comments on Zen Coding: Structuring Unit TestsBrian Rigsbyhttp://www.blogger.com/profile/09217041706921143546noreply@blogger.comBlogger15125tag:blogger.com,1999:blog-1625656052645899431.post-51146991027259623232018-01-17T08:12:27.583-08:002018-01-17T08:12:27.583-08:00Zen indeed: Works like a treat to three levels for...Zen indeed: Works like a treat to three levels for things like TestData, ProjDir etc. etc. though I used a public constructor instead of TestInit for now. I will get fancier for my DRY MSUnitTesting later but thankyou for the most elegant solution without having to suffer either of: global statics with cross Test Class references or repetition. Very glad indeed I voyaged hither and meditated here!Unknownhttps://www.blogger.com/profile/05643083247719991821noreply@blogger.comtag:blogger.com,1999:blog-1625656052645899431.post-76826618909686674692018-01-17T08:10:24.622-08:002018-01-17T08:10:24.622-08:00This comment has been removed by the author.Unknownhttps://www.blogger.com/profile/05643083247719991821noreply@blogger.comtag:blogger.com,1999:blog-1625656052645899431.post-13297637372186056522013-11-26T00:08:40.508-08:002013-11-26T00:08:40.508-08:00With xUnit you add the initialization code to the ...With xUnit you add the initialization code to the TitleizerTests constructor and it handles it ok. I'm not sure if it's good to do initialization in constructor tho...Anonymoushttps://www.blogger.com/profile/17960734282053673702noreply@blogger.comtag:blogger.com,1999:blog-1625656052645899431.post-58483747738474469482013-11-25T23:58:10.018-08:002013-11-25T23:58:10.018-08:00Thank you!
This was just what I was looking for.Thank you!<br />This was just what I was looking for.Anonymoushttps://www.blogger.com/profile/17960734282053673702noreply@blogger.comtag:blogger.com,1999:blog-1625656052645899431.post-59106991938530776832013-09-06T05:42:32.782-07:002013-09-06T05:42:32.782-07:00In Nunit and Re-sharper I worked around this by us...In Nunit and Re-sharper I worked around this by using the outer-class (TitleizerTests) purely as a container but add a separate abstract class outside of it but in the same namespace in which I place [TestInitialize], protected fields, helper methods, etc.., i.e: "TitleizerTestsBase".<br /><br />Then any inner test class inherits from "TitleizerTestsBase" instead, leaving the parent class act purely as a container.<br /><br />As the outer parent Class then only acts as a container you might even move "TitleizerTests" in to the namespace then, i.e: "namespace TestStructure.UnitTests.TitleizerTests"<br /><br />All you have then in the namespace is the abstract base class and all the test classes inheriting from the abstract base.<br /><br />This works for me and both, Re-sharper test runner NUnit app. Not sure this will also work for MSTest but you could give it a try and see.Anonymoushttps://www.blogger.com/profile/00149695585327290143noreply@blogger.comtag:blogger.com,1999:blog-1625656052645899431.post-86378547281350524562013-06-07T08:45:58.377-07:002013-06-07T08:45:58.377-07:00I see that the tests in my outer class get run mul...I see that the tests in my outer class get run multiple times ( 1 + number of inner classes). Is this right? Any way I can avoid it? I am using MSTest and Test Explorer.daahttps://www.blogger.com/profile/14932942075965102343noreply@blogger.comtag:blogger.com,1999:blog-1625656052645899431.post-31579735075677407182013-06-07T05:14:13.441-07:002013-06-07T05:14:13.441-07:00That's what I was going to suggest. I've g...That's what I was going to suggest. I've gotten burned on that a few times too. Thanks for reading the blog, I hope you found it useful.Brian Rigsbyhttps://www.blogger.com/profile/09217041706921143546noreply@blogger.comtag:blogger.com,1999:blog-1625656052645899431.post-45198772594103954662013-06-06T12:14:48.149-07:002013-06-06T12:14:48.149-07:00Nevermind - this was a typo on my end. Nevermind - this was a typo on my end. daahttps://www.blogger.com/profile/14932942075965102343noreply@blogger.comtag:blogger.com,1999:blog-1625656052645899431.post-16676305751849479112013-06-06T11:13:23.901-07:002013-06-06T11:13:23.901-07:00Neat idea. Visual Studio does not like the fact th...Neat idea. Visual Studio does not like the fact that I have initialized my protected variable from the outer class in the TestInitialize of the outer class. Resharper suggests converting the field to static but I am not like that suggestion - not sure if having a static field initialized in the TestInitialize and used by all the other tests is a good idea. Am I wrong in thinking this?daahttps://www.blogger.com/profile/14932942075965102343noreply@blogger.comtag:blogger.com,1999:blog-1625656052645899431.post-4899386389394182772012-11-27T06:15:02.722-08:002012-11-27T06:15:02.722-08:00I assume you are trying to reduce the duplication....I assume you are trying to reduce the duplication. <br /><br />One way to accomplish your scenario might be to create a series of "helper" methods that accept a parameter of the interface you are testing in the parent test class. Then call the methods in the nested test class for each type.Brian Rigsbyhttps://www.blogger.com/profile/09217041706921143546noreply@blogger.comtag:blogger.com,1999:blog-1625656052645899431.post-81942843988245719762012-11-27T05:50:01.647-08:002012-11-27T05:50:01.647-08:00That's not what I meant. I want to write a set...That's not what I meant. I want to write a set of tests against the interface methods, and reuse those tests for all implementations of that interface.<br /><br />It makes sense to me: My tests will enforce every implementation of that interface to comply with those requirements. Testing the interface signatures you're only checking if the return value of the methods is correct given a set of parameters. I see nothing wrong with it.<br /><br />Still I can't figure out how to use your approach in this scenario. I guess I'll be forced to place all the tests together in the abstract class.Sgrohttps://www.blogger.com/profile/14497976687495904135noreply@blogger.comtag:blogger.com,1999:blog-1625656052645899431.post-928976550712072982012-11-27T04:25:40.585-08:002012-11-27T04:25:40.585-08:00Interfaces really are not appropriate for unit tes...Interfaces really are not appropriate for unit tests as they have no behavior. If you have an abstract base class that implements the interface, then each concrete class that extends the base class should have their own set of unit tests. If the abstract base class has shared behavior or its own implementation of a method, this can be effectively tested using the very simple and excellent NSubstitute library to create a testable instance of your abstract class.Brian Rigsbyhttps://www.blogger.com/profile/09217041706921143546noreply@blogger.comtag:blogger.com,1999:blog-1625656052645899431.post-35735475060317171322012-11-27T02:49:10.523-08:002012-11-27T02:49:10.523-08:00I was trying this approach. It's fine as long ...I was trying this approach. It's fine as long as you're testing a concrete class. But what if you are making tests for an interface? I'd make an abstract test class that tests interface methods. Then I'd inherit this class to test a concrete implementation. With this approach, the "sub-classes for the methods" wouldn't be inherited. Any suggestions on how to address this?Sgrohttps://www.blogger.com/profile/14497976687495904135noreply@blogger.comtag:blogger.com,1999:blog-1625656052645899431.post-24931998670027906252012-01-26T09:11:45.053-08:002012-01-26T09:11:45.053-08:00good article. i like the grouping and readability...good article. i like the grouping and readability. you may want to change Appends... to Prepends... for better clarity of what the methods are actually doing.PadawanDeveloperhttps://www.blogger.com/profile/06118147735984144954noreply@blogger.comtag:blogger.com,1999:blog-1625656052645899431.post-23716039865159794022012-01-26T08:20:30.903-08:002012-01-26T08:20:30.903-08:00This comment has been removed by the author.PadawanDeveloperhttps://www.blogger.com/profile/06118147735984144954noreply@blogger.com