Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
If you're developing application using the code contracts, you may know, that this concept was introduced in Eiffel programming language.
I have become very confused after trying this concept in my C# application using System.Diagnostics.Contracts.
The main question for me is the next:
Are unit-tests really needed, if you have code contracts?
One of the major differences, that unit-test frameworks usually don't provide, is the possibility to call private methods (except MS fakes library with its shims). It's done, because of supporting composition & the idea, that private methods are covered by public method calls.
As for the code contracts, I can declare Contract.Requires, Contract.Ensures for private methods.
So, why do I need unit-testing, when I have code-contracts, which behavior is very similar.
Thanks
You surely need Unit testing.
With code contracts, you can only have your static contract verification.
There's much more you can do when running your code.
For example, say you are testing a class that depends on IConnectionProvider. What happens when your GetConnection throws? Code contracts won't help you with that.
Ideally you'd be testing the public methods of your class with different inputs, and verifying that it behaves as expected. This will help you find bugs, and in the long run, design better code.
I would say no. By using code contracts you are defining what your code is supposed to do and checking that it is doing it. The unit test does the same thing for the most part so I believe it is redundant to the point that it is not cost effective to write both.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I work in a code base that is quite large and today I found a project that was emitting IL code inside a normal class.
The project containing the IL code being emitted was a implementation of a Service Locator MSDN Desctiption.
What are the advantages of doing this and why would this be done as apposed to using the C# language?
Typically this is done to circumvent the overhead of using reflection, using information only available at runtime.
You would then use reflection, which can be slow depending on what you do, to build a new piece of code that works directly with the data given to it, without using reflection.
Advantages:
Performance
Disadvantages:
Hard to debug
Hard to get right
Hard to read code afterwards
Steep learning curve
So you need to ensure it's really worth the price before embarking on this.
Note that this is a general answer. In the specific case you came across, there is no way to answer why this was done nor which particular advantages (or disadvantages) you would have without actually seeing the code.
There are many uses for this.
One of the more often used scenario is for changing/injecting code on the fly:
.NET CLR Injection: Modify IL Code during Run-time
A good tutorial that help me to understand a good use for it is:
Dynamic... But Fast: The Tale of Three Monkeys, A Wolf and the DynamicMethod and ILGenerator Classes
Good luck
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
The project I am working on will have to be migrated from C# to F# based on what brings food on the table tomorrow - in other words, the two languages have to live side by side in this project for years to come.
The problem I am faced with repeatedly is how I should organize projects in the solution to meet this need.
I translate pieces from C# to F# all the time, because it frequently shortens the development time and increases the quality. But I end up with C# code that wants to use F# code, and F# code that want to use C# code, in the same layer, or at boundaries between layers or modules. I find myself putting code in the wrong projects just to avoid creating yet another project in some layer.
The situation is not bad now, but I worry that I will paint myself into a corner at some point, unless I can come up with a pattern or a structure, or simply understand the problem better.
Is there some modification to a normal F# architecture - a pattern, a substructure or a superstructure - that is well suited to such a mixed solution?
Are there patterns that are known to be especially helpful in solving this particular challenge?
Use an interface to communicate between the two languages.
Typically when porting, f# is the lower-level dll and C# can call f# as usual.
Now for f# to call c# define an interface in the f# dll (e.g. IClibApi) that is implemented in c# (e.g. ConcreteClibApi extends IClibApi). Create an instance of ConcreteClibApi and pass it to f#. Now f# can call c# thru IClibApi.
Later you can start porting ConcreteClibApi :)
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
If I've some common functionality that I've to keep in a class, so will I go for static, sealed or abstract class...Does all these types of classes serve the purpose of keeping the common functionality together...where actually the difference lies when I've to go for one
abstract, sealed, static has nothing to do with real time development. It has to do with bring structure within your software, so that the functionality implemented in classes can and should be used in the right way.
After some comments i think this:
I think you can only learn this, by doing it. There isn't a book or epub that will explain you how to do programming. They will show the syntax and some examples. It will be trial and error. Every day you'll face a new challenge.
You'll have to practice it. The best advise is, look what others already created and try to imagine why did they wrote/solve it that way.
I can explain what a static/sealed/abstract class is/does, but it doesn't learn you when to use it.
Back to the question: Define 'real time'.. I think that static/abstract/sealed should NOT be decisive on how you write your 'real-time' software. If you are 'scared' about performance on this level, C# should not be your choise. I would write c++ or if you want a real challenge, try to beat the compilers with asm ;-)
I think you won't measure the 'overhead'
So, use abstract/static/sealed in a right way, so your future collega's/you can read/maintain it.
I use C# for communication (tcp/ip) between a windows computer and a PLC (with delta robots). But it's far from realtime. It's fast enough to keep many robot working with > 100 messages per second.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
The project I work on has multiple layers and each layer's object is being used in the subsequent layer. But some of the classes do not have any interfaces and have non virtual methods. So basically I will not be able to use a mock framework to stud those classes from other layers. When I asked the developer to create an interface for the same class, so that I can mock it, he asked me why should I create an interface if I am not going to reuse it.
Is it a good practice to write interface just to improve the testability of the code?
Your code should be loosely coupled and has good dependency management to allow you write unit-tests easily. If you can't write unit-tests easily, it's the first sign that your code is not well-architectured enough, and you need to refactor it. So, your motivation to change production code(in your case to add Interface) should be to make your code better, not just to aid testing. If you could do the first - you would get the second for free.
Btw, one of the main benefits of following the TDD practice is that the good architecture is enforced from the beginning: it's difficult to write untestable code, because you write tests before you write code.
So, the answer is YES, it's OK to add Interface, but it should be done for the sake of good architecture, not just to help you write tests for bad architecture.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
I a have a solution containing 25 projects comprised of both C# and managed C++.
I need to test one of the C# project calls but this project is of type "Window application" (Not DLL).
Even though it is a windows application, my requirement is to call only few internal functional calls (Not related to windows form).
I need to create a separate C# test project to call this functionality. Is it possible to do it like this?
Can anyone suggest a way or examples? And one more thing, I cannot modify the existing code.
Is it possible to do it like this?
Yes. Referencing the project you wish to test in a test project is typically how you unit test your code.
Can any one suggest a way or examples?
Create a unit test project, reference the project that contains the code you wish to test, write tests to test the code you wish to test. If you need to refactor the code to make it testable, do so, or see point below.
And one more thing, i don't have any freedom to modify the existing
source code.
In this case, you are going to have to wrap the code in some cleaner interfaces to allow you to test the code.
The book, Working Effectively with Legacy Code by Michael Feathers has some excellent advice on how to get legacy code under test.