|
I think unit testing should be done through "normal" code and techniques, which means:
1) Don't add extra code to the original source and remove it after the test, because this way you aren't testing the orginal code.
2) Avoid using special weapons, such as reflection, platform invoke or special debug support. These just make your testing more complicated but less convincing.
If the private constructor is not supposed to be accessed, don't call it directly. No difference from any other private methods. You still can cover the constructor through your first call to Instance() method.
Best,
Jun
|
|
|
|
|
|
Jun Du wrote: Avoid using special weapons, such as reflection
 I couldn't unit test without reflection. How do you otherwise test non-public methods, which, in my case, is almost everything; I always opt for internal rather than public, since public can be called by other assemblies. And if your code can be called by other assemblies, a whole new set of rules apply: try running your assembly under FXCop and have a look for yourself.
Reflection is a great tool for unit testing.
One thing I've found very helpful, which also has alleviated my reliance on reflection, is the InternalsVisibleToAttribute. Put this on your assembly to expose all internal members to your unit tester assembly. From there, you no longer need to use reflection to access internal members.
Tech, life, family, faith: Give me a visit.
I'm currently blogging about: Messianic Instrumentals (with audio)
The apostle Paul, modernly speaking: Epistles of Paul
Judah Himango
|
|
|
|
|
Judah Himango wrote: I couldn't unit test without reflection. How do you otherwise test non-public methods,
Non-public methods are not exposed to outsiders. How do you use them in your applications? Use them internally.
We should do the same thing in unit testing. Write some test cases, each of which is designed to test certain non-public methods, but through public interfaces or methods.
BTW, we usually don't test the compiler-generated code (designer code).
Best,
Jun
|
|
|
|
|
Jun Du wrote: How do you use them in your applications?
This is where I have to disagree. The very name "unit testing" means that you're testing a single unit, not the application. Unit testing is good for telling you how well a unit works by itself. Integration testing would tell you how things work together. It's not just about non-public methods, I could have classes that are internal and I believe they should be tested as well.
Logifusion[^]
|
|
|
|
|
Well, it all comes down to how we define what a unit is, a method, a class or a module? I often find class is a good candidate as a unit, but the granularity really is relative.
Also, it would be desirable to test a method in the context of an object, as the object state often has decisive effect on the method itself. Maybe that is one area where C++ differs than C.
Best,
Jun
|
|
|
|
|
Judah Himango wrote: One thing I've found very helpful, which also has alleviated my reliance on reflection, is the InternalsVisibleToAttribute. Put this on your assembly to expose all internal members to your unit tester assembly.
I see this is new in .NET 2.0. This would have been handy on a post-hoc unit testing assignment I worked on a few months back.
Kevin
|
|
|
|
|
Judah Himango wrote: One thing I've found very helpful, which also has alleviated my reliance on reflection, is the InternalsVisibleToAttribute. Put this on your assembly to expose all internal members to your unit tester assembly. From there, you no longer need to use reflection to access internal members.
I actually tried that - It looked extremely promising, however it didn't seem to work. It threw up a warning about not being able to find the assembly referenced in the Attrbute and when I tried to access it from the test class it still complained that it was private.
The assemblies are all strong named, so I'm guessing I'm just not doing something right when I give it the strong name of the "friend" assembly.
Scottish Developers events:
* .NET debugging, tracing and instrumentation by Duncan Edwards Jones and Code Coverage in .NET by Craig Murphy
* Developer Day Scotland: are you interested in speaking or attending?
My: Website | Blog
|
|
|
|
|
|
|
|
Colin Angus Mackay wrote: So, for the purposes of unit testing it would be useful to have more than one instance of the class available. Or perhaps there is another solution.
I'm not sure this solution will work for you, Colin, but one thing I've done for classes that are typically single instance only classes is something like this:
public class SomeClass()
{
private static SomeClass instance = new SomeClass();
private SomeClass()
{
}
public SomeClass Current
{
get
{
return instance;
}
}
}
This way, SomeClass can still implement interfaces necessary for using mocks (whereas static classes cannot implement interfaces), it can be instanciated (using reflection or Activator.CreateInstance), and is quite easier to test than a pure static class. In fact, I only use static classes for places that have totally, 100% "functional" functions; where each function relies only on itself or other functions in the same static class; no variables or shared state at all. If you find yourself requiring lots of state and shared data; go with an instance class, IMO.
If you need static access to the instance class and you need only 1 instance of the class, the above code works well.
Tech, life, family, faith: Give me a visit.
I'm currently blogging about: Messianic Instrumentals (with audio)
The apostle Paul, modernly speaking: Epistles of Paul
Judah Himango
|
|
|
|
|
You could inherit the singleton and put the [Test] blocks on the new class which does have a public method. Or you could wrap the public constructor of your singleton within #if DEBUG directives causing a compile time error on release mode if someone misused your class.
A man said to the universe:
"Sir I exist!"
"However," replied the Universe, "The fact has not created in me A sense of obligation."
-- Stephen Crane
|
|
|
|
|
all font have script with any language inclue in this font
how can get the script in some font with c# ??
Palestine
|
|
|
|
|
Could you please rephrase this in something closer to proper english?
Regards,
mav
--
Black holes are the places where god divided by 0...
|
|
|
|
|
when u open notepate and go to select font from menu
u can see (Script) and comboBox withh all language support in this font ??
i want to make comboBox that have a list with script .. as in the NotePad
how can get this Script with C#
Palestine
|
|
|
|
|
You want a font combo box. I'm sure there are some on this site, if you do a search.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
Ok, now I think I see what you mean.
I've never bothered to look at the "Script" combobox in the FontDialog, but I think the only effect of selecting a different value from the combobox is to show a different set of characters in the preview window.
Unicode charsets contain ranges of special characters (for example, Greek, Kyrillic (sp?) or Hebrew characters) and I think the "Script" refers to one of these groups.
But I don't have an idea if you can get a list of these groups with .NET, sorry...
Regards,
mav
--
Black holes are the places where god divided by 0...
|
|
|
|
|
see this lik
http://imgsrv.worldstart.com/ct-images/notepad-font.jpg
Palestine
|
|
|
|
|
You can use FontDialog
FontDialog dlg = new FontDialog();
if (dlg.ShowDialog()==DialogResult.OK)
{
selectedFont = dlg.Font;
}
|
|
|
|
|
i dont want to use FontDialog
i want to make one like it ...
Palestine
|
|
|
|
|
Hi People,
I would like to write a program in c# which will interogate all incoming webpages for bad language etc before allowing it to displayed by the browser.
Trouble is I have no idea where to begin. Can anyone point me in the right direction with articles or advice?
cheers
CJ
|
|
|
|
|
Well, I would begin by ignoring the browser entirely.
You should start any project like this with the "engine" part. In your case this engine takes a string (which may later be the HTML sent to the browser), and parses that string for a known database of "bad words" or phrases.
It might remove these bad words from the input string, replace them with something, or totally dis-allow the entire input string....that is the bit you decide.
When your engine works to your satisfaction, start to think about how to implement your engine - you suggest you could intercept incoming HTML and do something with it before it hits the browser. That is certainly possible, but will require a good solid knowledge of the inner workings of the OS, the browser and HTTP.
In addition, if you are writing a contant filter, much work is done internationally around standardising such protocol. Many websites, for example, include a header with some form of content rating. You should research this as appropriate to your project.
---
How to get answers to your questions[^]
|
|
|
|
|
Thanks for your help. Im not too concerned about writing the engine part at the moment but more the actual intercepting of HTTP and stopping it from reaching IE is more of a concern. Any idea how to do this?
|
|
|
|
|
You can try to hook WINSOCK calls and change the content or prevent it.
Try madshi:
Madshi
Eran Aharonovich (eran.aharonovich@gmail.com )
Noviway
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
