What should i unit test here [closed] - c#

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 4 years ago.
Improve this question
Let's say i have method like that
What should i test over here:
public Subscription ChangeState(TestClass testClass, DateTime currentTime)
{
testClass.IsDisabled = true;
testClass.IsDelete = true;
Update(testClass);
_logger.LogInfo($"Some Error message is going here");
return testClass;
}
First that come to my mind only test IsDisabled and IsDelete state adter test
Are there additional cases for testing?

It all boils down to what the method is supposed to do exactly rather than its current code, but given what you've got, I can find some dead simple tests:
The parameter must be the same as the return value.
Assert that both properties are set to true if sent as false.
If the properties are both true, is it really necesary to call Update? This is a potential improvement that a test can discover.
Check that Update is really called. Since this is another method (we don't know if private or what) you may verify its side effects.
If no error happens, there is no need to log an error message, that's a possible bug in your implementation (although not sure if it merits a unit test).
A clear bug is that the method doesn't check for nulls, a test will easily check that.
Not for wirting an unit test, but the currentTime parameter is not used at all and should be removed.

Related

Question on returning no value from method [closed]

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 2 years ago.
Improve this question
I have a function that works as intended:
public IWebElement ParseTheSelectElement(string byElement, int byRandomValue)
{
new SelectElement(_driver.FindElement(CustomSelector.Parse(byElement))).SelectByIndex(byRandomValue);
return null;
}
I'm using Selenium to select an index from a dropdown going by an index, i don't need anything returned from the method as the code executes fine, i know if nothing is to be returned to use void i had to return something to avoid an error so i did return null; i'm trying to learn if this is the correct way to handle this?
I have no errors, i'm just really wanting to learn if this is valid, it does not look correct to me as i'm not returning anything. Thank you for any input.
I have no errors, i'm just really wanting to learn if this is valid, it does not look correct to me as i'm not returning anything.
It seems your intentions are to not return anything, rather perform an action, if that's the case, then make it a routine and or method and not a function that is intended to return something.
public void ParseTheSelectElement(string byElement, int byRandomValue)
{
new SelectElement(_driver.FindElement(CustomSelector.Parse(byElement))).SelectByIndex(byRandomValue);
}
You may be trying something like:
_driver.FindElement(CustomSelector.Parse(byElement)).SelectByIndex(byRandomValue);
If you do the above, FindElement may not return an element, if so, then SelectByIndex would throw. With this in mind, you may want to check if the FindElement actually return's an element before doing anything with it.
Again, not sure though what your intentions are here, you're creating a new instance of SelectElement, but why, you're not doing anything with it.

How to pass a pinged username and a variable to a bot command [closed]

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 3 years ago.
Improve this question
I am trying to make a ranking system bot and I need to be able to pass in the command another user and an int variable like
[Command(/*#user*/ + " Has won round " + /*int*/)]
Is it even possible? (keep in mind I am pretty much a noobie so a simpler solution is generally better for my needs)
Edit: I forgot to add the discord.net part also in the title which has caused some misunderstandings but now it is fixed. also a little bit of fixing to the wording
The code snippet you provided is completely invalid. The Command attribute is used to define the command name, not accept parameters for the command. Expected command input (command parameters) are set in the command method's signature.
// example command call: !sample #RandomUser 25
[Command("sample")]
public async Task ExampleCommand(IUser user, int num)
{
// Do stuff
await ReplyAsync($"{user.Mention} has won round {25}");
}

two differents method or additional parameter? [closed]

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 have a method set in an POCO entity that set the basic property and the navigation property. In some cases, I don't need to verify some conditions, but in another cases I need to verify to ensure that the information is coherent in the database, but this verification makes me to get extra data from database.
So by the moment I have my basic method that is this:
public void setMyProperty(MyType paramProperty)
{
this.Property = paramProperty;
this.IDProperty = paramProperty.IDPorperty;
paramProperty.MyNavigationCollection.Add(this);
}
For the method that verifies the data, I guess that I have two options.
First one, I can create a new method for business logic, somthing like that:
public void setPropertyBi(MyType paramProperty)
{
//check conditons
//If all OK then
this.setPorperty(paramProperty);
}
But I have another option, use only one method, not the basic method and the other for business checks. Something like that:
public void setProperty(MyType paramType, bool paramDoChecks)
{
if(paramDoChecks)
{
//Do checks
}
//if all OK
this.Property = paramProperty;
this.IDProperty = paramProperty.IDPorperty;
paramProperty.MyNavigationCollection.Add(this);
}
Which is the recommended option? or there are another ways?
People here seem to prefer the flag, I personally think it is horrible.
You want to achieve two different things: just set a property; validate AND set a property. IMHO it should be two separated methods.
Just don´t write two different Methods if it´s one equaly functionality. Just add a Parameter which makes the validation-difference like you´ve written last.
But don´t forget to enter the behaviour if validation failed. separate it well.
You could add a Boolean ValidationRequiredproperty to MyType which you can set before the call to setMyProperty().
I prefer to have two methods: CanSetProperty and SetProperty.
CanSetProperty: just check the condition, does not change anything in the parameter.
SetProperty: will modify the paramenter.
I think this code is a good candidate to follow the Command Query Separation Pattern
The fundamental idea is that we should divide an object's methods into
two sharply separated categories:
Queries: Return a result and do not change the observable state of the
system (are free of side effects).
Commands: Change the state of a
system but do not return a value.

Are 'Has' Properties Good Practice? [closed]

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
Sometimes in my models, I implement get only 'Has' properties (e.g. HasDescription) so I can easily check the validity of a property from outside my model with if (model.HasDescription) { ... }.
The implementation might look something like:
public bool HasDescription => Description != null && Description != string.Empty;
Is this good practice? More specifically, if I do take this approach should I move this conditional logic elsewhere? Perhaps into extension methods?
It's a matter of personal preference sometimes; having a bunch of HasX properties can be OK. I sometimes do it for validation reasons (I found it works well to use a property like that for an MVC app when using FoolProof). It can be cumbersome to have to add a bunch of HasX properties though... So, if you are using these for evaluations in your controller, it's a matter of personal preference. If that is the approach you want to take, I wouldn't worry about it.
If you are using it for validation purposes, sometimes when you need model-based evaluation, you can use an IsValid method for determining validation status. That would be more MVVM-like than MVC-like, but it works.
Has is completely legitimate. However, the logic belongs in the setter or in the constructor: decide on a way to represent a missing property (null or string.Empty, preferably null, but definitely not both). This leaves the Has logic to check for null.
One consideration in favor of dropping Has altogether is the possibility of using ?? operator. If your use cases allow you to replace
var xyz;
if (x.HasXyz) {
xyz = h.Xyz;
} else {
xyz = defaultValueOfXyz;
}
with
var xyz = h.Xyz ?? defaultValueOfXyz;
then you can drop HasXyz altogether.

MSTest - why is there no AreEqual(object, object, IComparer<T>)? [closed]

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.

Categories