|
Shankar M wrote: getting an error
Incorrect syntax near ')'.
Remove the ) after clean.
This space for rent
|
|
|
|
|
Thanks for your suggestion
|
|
|
|
|
Which unit testing framework for C# can create unit tests automatically?
|
|
|
|
|
What do you mean by creating unit tests automatically? Are you referring to tests like PEX and MOLES or Intellitest?
This space for rent
|
|
|
|
|
I mean that I have a code that contains some methods...
I'm looking for a tool that would go over my code and create unit tests for the methods automatically... Does a tool like that exist in the market?
|
|
|
|
|
To a certain extent, yes it does (see the links in my original post to PEX and Moles from Microsoft research). The real question is, how much value do these tools provide? For instance, it's simple enough to automatically check whether or not a value is null but what about range checks? Would a tool know that your code expected a value between 0 and 5? Don't fall into the trap of just blindly adding tests, which is the problem with this idea. Your tests should really be there to exercise the expected logic of your code; for instance, if you changed the acceptable range from 0 to 6 and passed 6 into the code expecting the test to follow the fail path, it would suddenly follow a different path through your code so you would know that your test needs to change.
This space for rent
|
|
|
|
|
No framework can predict your expected results; so there's no such thing as creating tests automatically.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Is it possible to test several cases of the method under test?
|
|
|
|
|
Yes, you can throw random values at it.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
You could try some Property-Based Testing[^]. Frameworks like FsCheck automaticaly generate random values to verify your properties. But you have to come up with properties that you need to verify yourself.
Such approach is more reliable then unit-testing against magic-numbers and is helpful to spot bugs but can only be used in the limited cases
Also again I'm not 100% sure whether this is what you're looking for
|
|
|
|
|
Not really a question but I would like some feedback.
I have been programming in C# for years now and until today I never could find a way to use the ref keyword in a syntax-correct way. I'm writing code to build XML based on data classes for what must be the thousandth time. The simplest way to generate the data is in plain old strings but I needed a fast way to check for reserved XML characters and update the string only if necessary. Strings are immutable and I don't want to have to copy the string if necessary as this just adds overhead so I came up with this:
public static bool ContainsReservedXmlCharacters(string value)
{
char[] reservedCharacters = new char[] { '<', '>', '&', '%' };
for (int i = 0; i < value.Length; ++i)
{
if (Array.Exists(reservedCharacters, delegate (char c) { return c.Equals(value[i]); }))
return true;
}
return false;
}
public static void ValidateForXml(ref string value)
{
if (ContainsReservedXmlCharacters(value))
{
value = String.Format("<![CDATA[{0}]]>", value);
}
}
This way, I can check the string if contains characters that it shouldn't and only replace the string if necessary. Experience has taught that reserved characters do sneak into XML from time to time but not that often. This should save some parsing time as the string is copied infrequently. I could even write the function to escape the reserved characters if needed.
If there is still a use for ref, it is with handling immutable types such as strings in functions where they may or may not be replaced with a new value.
What does the community think about this?
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
Foothill wrote: What does the community think about this?
I think you should be using System.Xml.Linq[^] to build your XML documents. 
If you build your own XML generator, you're bound to run into edge cases that you hadn't considered.
For example, if your input contains "Test]]>", your "valid" string will contain "<![CDATA[Test]]>]]>", which is not valid XML.
Using XLinq:
new XCData("Test]]>") gives:
<
If you can't read my code, try converting it here[^]
|
|
|
|
|
That's news to me. Do you happen to have a reference to that? I was operating on the assumption that immutable types are passed by copy and not by pointer, hence the need for ref so that it could be passed by pointer and replaced if necessary.
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
I'll be googling for a reference after the groceries; I'm out of coffee and that's a priority.
I vaguely remember something about string.Clone that doesn't return a clone, because it is "immutable" and the string will only exist in memory once.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Coffee works miracles. Only "interned" strings are kept in memory in that way, and if your string doesn't come from a literal but from user-input, this doesn't happen automatic.
The string is still a reference-type, and its value 'should' not be duplicated as with a value-type. Passing it with the ref keyword means that you are modifying the data of supplied variable. Since the alternative does return a new immutable string, what you said makes sense 
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
I agree with the previous commentator that for this specific case System.Xml.Linq is the best tried and true solution.
However, if we take a look at the broader case
Quote: If there is still a use for ref, it is with handling immutable types such as strings in functions where they may or may not be replaced with a new value.
then how about working with mutable type instead of immutable? i.e. StringBuilder[^]
|
|
|
|
|
Since I was building this to process inputs from users into an XML document and the statistically low incidence of invalid characters, StringBuilder was not the best option in this case. The data exists as a bunch of strings already and copying them all to a StringBuilder on the off chance they will be changed seemed wasteful. I wanted to combine the validation and replacement operations into a single step but without the need to create copies of a string in memory unnecessarily. The code itself is run-of-the-mill. I was just surprised to actually find a language-correct appllicaton for ref as I have never been able to put it to use before.
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
Perhaps "ref" has more of a place when it comes to "inter-op".
It seems there is frequent use "ref" in C# when talking to MS Word, for example:
Globals.ThisDocument.CheckSpelling(
ref missing, ref ignoreUppercase, ref missing, ref missing, ref missing, ref missing,
ref missing, ref missing, ref missing, ref missing, ref missing, ref missing);
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
That's not so much of an issue since C# 4 was released. You can omit all of the ref missing arguments, and use named arguments for the ones you want to pass.
And I believe you may be able to omit the ref on the other arguments as well (for Interop calls only); but don't quote me on that.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
That also makes sense. The MS documentation on ref is a little confusing since technically all objects are passed by reference (i.e. pointer). Since C# does everything it can to hide all the pointer shenanigans, I do believe it was tacked on to show that a method argument is being passed by pointer and highlight that the pointer passed to the method might not point to the same location when the function exits. Passing pointers around in C++ is common and I believe this was their way of representing it.
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
The short answer is: "value types" (like int) are passed as / by "value". In order to "update the source", you need to pass them "by reference" via the "ref" keyword.
Another example is the "Interlocked" commands; which allow you to update "value type refs" (e.g. "counters") concurrently from multiple threads as atomic operations.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
Foothill wrote: all objects are passed by reference
Slightly confusing two different things. Reference types are passed as references (pointers), but they are not passed "by ref".
You can update things in the reference that the parameter points to; but if you change the parameter to point to a different reference, that change won't be seen by the caller.
Adding ref (or out) to the parameter means that, if you change it to point to something else, that change will be seen by the caller.
My C++ is terribly rusty, but I believe it's equivalent to passing either a * (by value) or a ** (by ref) parameter.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Richard Deeming wrote: I believe it's equivalent to passing either a * (by value) or a ** (by ref) parameter.
I don't really see it like that, but I may be wrong.
I see a pointer as a inherent array of values whose type is this of the pointer (a char* as an array of characters, for example).
I see a pointer to a pointer as a bidimensional array (a char** as an array of arrays of characters).
I like the possibility in C++ to specify the const-ness of either the value pointed to, or the const-ness of the pointer itself.
void func(const object* obj) allows to change the address to which obj is pointing, but not the value of the eventual members which obj could have.
void func(object* const obj) forbids to change the address to which obj is pointing, but allows to change the values of its eventual members.
void func(const object* const obj) forbids to change the address to which obj is pointing as well as any modification to object members.
In that sense, C++ is more versatile as it allows to control very precisely the mutability of the objects we are using. In C#, controlling the mutability of an object implies a lot more code and complexity.
Again, I am quite fresh in C++, so I may be wrong, or incomplete on the subject.
"I'm neither for nor against, on the contrary." John Middle
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
