home
products
contribute
download
documentation
forum
Home
Forums
New posts
Search forums
What's new
New posts
All posts
Latest activity
Members
Registered members
Current visitors
Donate
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Search titles only
By:
Menu
Log in
Register
Navigation
Install the app
Install
More options
Contact us
Close Menu
Forums
MediaPortal 1
Development
Submit: code patches (MediaPortal/TV-Server/etc.)
Repair & Update Unit Tests
Contact us
RSS
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="Tony Wall" data-source="post: 1081228" data-attributes="member: 125233"><p>Been on holiday... in response to the various points:</p><p></p><p><u><strong>Moq vs. NSubstitute</strong></u></p><p>[USER=86308]@mnmr[/USER] I agree, on further examination although they seem similar the following post confirms at least one good reason to choose NSubstitute over Moq. </p><p><a href="http://dennis-nerush.blogspot.de/2012/10/rhino-mocks-vs-moq-vs-nsubstitute.html" target="_blank">http://dennis-nerush.blogspot.de/2012/10/rhino-mocks-vs-moq-vs-nsubstitute.html</a></p><p>AutoFixture also supports NSubstitute so that's okay too.</p><p>Switching from one tool to the other is no big issue, they usually follow the same pattern. Having any kind of asserted "fact" (test) in any decent form of code is most important.</p><p></p><p><strong><u>Frameworks</u></strong></p><p>I'm not one of those people who uses a framework for a the sake of it. I'm more of an old school component and object orientated developer who tries to make sound design decisions first leading to a more elegant object model not requiring bloating or overhead of additional runtime frameworks. I know what I'm talking about. I've used the Patterns & Practices of Microsoft right from the start. The P&P team themselves advise their frameworks/extensions usually end-up in a more compact/concise form in the next version of the .NET Framework itself. Dependency Injection and Log4Net (the competitor to Logging Application Block from MANY years ago) are simply not required in most (if not all sensible) cases. Just consistently use good design and built-in features, i.e.</p><p>* Component architecture</p><p>* Interfaces where extension is supported</p><p>* A simple factory pattern only where needed</p><p>* Trace sources with logical names/splits</p><p>* Good code documentation and clear log messages</p><p>* Standard binding redirects for versioning</p><p>* Strong names to support GAC and isolate processor specific limitations</p><p>MP1 fails quite a bit here and is a legacy product so I wouldn't even try to do too much here. Maybe I could bring something positive to MP2 later.</p><p></p><p><strong><u>Scope</u></strong></p><p>My initial goal is to be able to unit test patches in MP1, to cover some essential core features I feel are not working right (at least for me) and to provide a place for others to put some new tests in if they want to. The only framework switching here is replacement of 3rd party or legacy components with NuGet open source alternatives so the build works on every developer PC without external fiddling/installation/inconsistency. I will check out MP2 source to make sure I'm not going against a previous decision, if there is one/evidence/code which covers these concerns, then start a new discussion about that as necessary. That should not delay submission of a properly tested MP1 patch though.</p></blockquote><p></p>
[QUOTE="Tony Wall, post: 1081228, member: 125233"] Been on holiday... in response to the various points: [U][B]Moq vs. NSubstitute[/B][/U] [USER=86308]@mnmr[/USER] I agree, on further examination although they seem similar the following post confirms at least one good reason to choose NSubstitute over Moq. [url]http://dennis-nerush.blogspot.de/2012/10/rhino-mocks-vs-moq-vs-nsubstitute.html[/url] AutoFixture also supports NSubstitute so that's okay too. Switching from one tool to the other is no big issue, they usually follow the same pattern. Having any kind of asserted "fact" (test) in any decent form of code is most important. [B][U]Frameworks[/U][/B] I'm not one of those people who uses a framework for a the sake of it. I'm more of an old school component and object orientated developer who tries to make sound design decisions first leading to a more elegant object model not requiring bloating or overhead of additional runtime frameworks. I know what I'm talking about. I've used the Patterns & Practices of Microsoft right from the start. The P&P team themselves advise their frameworks/extensions usually end-up in a more compact/concise form in the next version of the .NET Framework itself. Dependency Injection and Log4Net (the competitor to Logging Application Block from MANY years ago) are simply not required in most (if not all sensible) cases. Just consistently use good design and built-in features, i.e. * Component architecture * Interfaces where extension is supported * A simple factory pattern only where needed * Trace sources with logical names/splits * Good code documentation and clear log messages * Standard binding redirects for versioning * Strong names to support GAC and isolate processor specific limitations MP1 fails quite a bit here and is a legacy product so I wouldn't even try to do too much here. Maybe I could bring something positive to MP2 later. [B][U]Scope[/U][/B] My initial goal is to be able to unit test patches in MP1, to cover some essential core features I feel are not working right (at least for me) and to provide a place for others to put some new tests in if they want to. The only framework switching here is replacement of 3rd party or legacy components with NuGet open source alternatives so the build works on every developer PC without external fiddling/installation/inconsistency. I will check out MP2 source to make sure I'm not going against a previous decision, if there is one/evidence/code which covers these concerns, then start a new discussion about that as necessary. That should not delay submission of a properly tested MP1 patch though. [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
Development
Submit: code patches (MediaPortal/TV-Server/etc.)
Repair & Update Unit Tests
Contact us
RSS
Top
Bottom
