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
Writing UnitTests with MSTest I want to assert the equality of a return value vs. the one I'm expecting.
Expected type is a custom type that does not implement the IComparable interface nor the IEquatable interface, thats why I want to give Assert.AreEqual a possibility to compare the two objects.
I am aware that this possibility exists in CollectionAssert.AreEqual. This method however requires two ojects that inherit ICollection which my objects do not.
Why does Assert.AreEqual not allow me to specify a custom comparer? Am I missing something?
Not sure if this is the actual reason, but what if your custom IComparer was faulty - your unit test would be meaningless (bearing in mind that the test framework has no way to tell if you wrote unit tests for it let alone if they are "correct")
Could you just create a comparer in your test?
var com = new MyComparer<Foo>();
int expected=0;
int actual = com.Compare(a,b);
if (actual!=0)
{
Assert.Fail("oops");
}
Maybe not ideal, but should work...
I also found this question from a few years ago on msdn, with no answers - but an interesting approach to the workaround by the question poster.
Related
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 3 years ago.
Improve this question
I have a methode searching for a winform control by name. My first approche was to do it like that
private Control SearchControlByName(Control parent, string name){recursive search...}
Calling the methode looks like
Label temp = (Label)SearchControlByName(panel1, "label4");
Then a thought to myself it would be better do do it with an generic methode like this
private T SearchControlByName<T>(Control parent, string name) where T : Control {recursive search}
calling like
Label temp = SearchControlByName<Label>(panel1, "label4");
And now I'm not sure which is the better approach. What are the advantages / drawbacks of the generic method vs casting after calling the method?
In the generic methode I also have to cast the result like this
return (T)result
I don't think there are any disadvantages.
Since there are at least two advantages (see below), I would use the generic version.
It's prettier (no need for that cast).
You could use OfType<T> on Control.Controls inside the implementation (your recursive search) so you don't have to worry about returning a Label when the person wants a PictureBox. However keep in mind that you can only do that at the bottom level, otherwise you won't go through all the elements of course.
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
I've got this idea from Java - i was told that you should declare a collection like this
List<Object> myList = new ArrayList<Object>();
where ArrayList is a class implementing List interface. The point of this is to enhance maintainability by generalizing code - as, should you change teh implementation to, e.g LinkedList<Object>, you could to it 100% painlessly.
So, projecting this on C#, is it considered a good practice to do the same thing in C# :
IList<Object> list = new List<Object>()
?
EDIT : i just found that LinkedList in C# does not even implement the IList interface, so i guess it settles the question for lists at least
Yes, generally this is a good practice to use interfaces wherever you can.
There are two important exceptions for containers, though:
When you must use a hash-based container for objects that are not comparable, use HashSet<T> or Dictionary<TK,TV>,
When you declare a local variable, using var for implicit typing is often preferred for convenience,
Note that if you plan to use a sorted container you have IOrderedSet<T> and IOrderedDictionary<TK,TV>.
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 7 years ago.
Improve this question
Assuming:
"personList" is a list of Person objects
"agent" is an object that can provide activity about Shop objects (a property of Person)
"GetShopActivity" returns a list of shopping activity objects for a Person
I have this line in a test project:
personList.ForEach(p => new List<Person>(p.Shops)
.ForEach(t=> Assert.IsNotNull(agent.GetShopActivity(t, startDate, endDate))));
How can I make it better?
There is probably a lot you could do, but the first thing to do would be to make it more readable. Perhaps something like this:
var nullActivities =
from p in partnerList
from t in p.Tenants
let activity = agent.GetShopActivity(t, startDate, endDate)
where activity == null
select activity;
Assert.Empty(nullActivities);
Moreover:
you may want to think about
a test should be simple (i.e. it should have a Cyclomatic Complexity of 1).
it should be immediately evident to a person reading the test what scenario and behaviour is being tested (in case the values of startDate and endDate are significant it might be beneficial to give them less generic names).
prefer having only a single assertion as that makes it easy to know where the test failed when it fails.
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 7 years ago.
Improve this question
Is there any preference on either appending DTO or Entity to a class name?
Is there any standard around this?
1 Class is used by ORM (EntityFramework) and the other class is used for serialization.
The reason for this is so that there is no duplication of all fields as the EntityFramework is a wrapper around the DTO class(most but not all properties).
The DTO class is in a shared library, and decoupled from EF.
E.g. Which of these is the most common/standard approach?
// 1.
MyNamespace.Entities.MyClass
MyNamespace.Models .MyClassDto
// 2.
MyNamespace.Entities.MyClassEntity
MyNamespace.Models .MyClass
// 3.
MyNamespace.Entities.MyClassEntity
MyNamespace.Models .MyClassDto
In my personal experience your third example is the only implementation I have worked with and it is the one I would argue for because the intent of the object you are working with will always be clear whereas with the other two it only becomes clear when looking at both objects together.
That being said as long as your team comes to an agreement on which to use any would work.
In my opinion, you typically don't want to put implementation details into class names for similar reasons to why you don't want to use Hungarian Notation.
If there's a bit of code that needs to work with both types and differentiate between them, another option is including aliased using statements like this:
using entities = MyNamespace.Entities;
using dto = MyNamespace.Models;
//in code
var myClassEntity = new entities.MyClass();
var myClassDto = new dto.MyClass();
//work with both
My assumption is that the code that needs to work with both types is limited to an isolated library, and that client code typically works with one, not both types.
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
What is better method to use for object preparation logic:
a) with return value
List<Users> users = LoadUsers();
users = PrepareUsers(users);
b) or with void type
List<Users> users = LoadUsers();
PrepareUsers(users)
Are you setting properties on existing User objects or are you creating new ones?
If you're simply changing existing objects, then there's no reason why you'd want to return them, it's redundant. Worse, it's misleading - the client will think his objects were left untouched and that you're creating new objects when in fact you're not.
If you're creating new ones, well then, you obviously need to return them.
Alternative b. since you are working with the same user objects, there is no reason to reassign the variable.