I have a method that accesses variables local to the class itself. I'm wondering if that's a design flaw because now my unit tests are dependent on those variables being set. Is it weird/wrong to pass those variables to the method, even though that method has direct access to those variables? (If the method accepts those variables as parameters, then the unit test can also pass its own variables to the method.)
For example, here are the variables local to the class:
private static List<string> _whitelistNames = GetWhitelistNamesFromConfig();
private static List<string> _blacklistNames = GetBlacklistNamesFromConfig();
And the method looks something like this:
private static bool ThisProcessorHandlesThisFoo(Foo foo)
{
if (_whitelistNames.Count > 0)
{
// We're doing this instead of Contains() so we can ignore case sensitivity.
bool found = ListContainsString(_whitelistNames, foo.Name, StringComparison.OrdinalIgnoreCase);
// Some logging here
return found;
}
if (_blacklistNames.Count > 0)
{
bool found = ListContainsString(_blacklistNames, foo.Name, StringComparison.OrdinalIgnoreCase);
// Some logging
return !found;
}
throw new InvalidOperationException("some message");
}
In order to do what I'm suggesting, I would need to change the method signature to this:
private static bool ThisProcessorHandlesThisFoo(Foo foo, List<string> whitelistNames, List<string> blacklistNames)
Then the calling code (in the same class) would have to pass the local variables to the method. This would allow my test code to send its own parameters. Am I missing something? Is there a better way to do this? (It just seems odd to pass parameters that the method already has access to. But perhaps this is a good decoupling technique.)
You shouldn't have to worry about this.
Your unit tests should be testing the interface to your class (public methods and properties), and should not depend on any implementation detail (like a private class property). This allows the implementation to change without breaking other code (and hopefully without breaking existing tests).
Those private static fields should be initialized when the class is instantiated (according to your code, they have initializers). Are they initialized when it's instantiated for your unit test? They should be... It's a generally accepted idea that when the constructor for an object is finished running, the class should be in a usable state, and you're indicating that this isn't always the case.
This is an example of where something like Dependency Injection could be useful. You then pass these kinds of things to the constructor of your class (or through another means), and allow the part of the program that creates it (either your normal program or your unit test) to "inject" them into the class.
You should not test private methods, test the public ones in the way that tests cover all the class' code branches(including ones in private methods).
I'd recommend you to change method signature(to ThisProcessorHandlesThisFoo(Foo foo, List<string> whitelistNames, List<string> blacklistNames)) rather than use fields. As per my experience, such approach makes classes much easier to read and maintain.
Related
I was unclear in an earlier question I ask so I will try to be more explicit.
Is there a way to put a static class inside of a dictionary so that its functions can be called? If this is not possible, what is the best alternative that doesn't involve using instances that you can suggest?
Here is how I would like to use it:
static class MyStatic : IInterface
{
static void Do(){}
}
static class MyStatic2 : IInterface
{
static void Do(){}
}
class StaticMap
{
static Dictionary<Type,IInterface.class> dictionary = new Dictionary<Type,IInterface.class>
{
{Type.1, MyStatic}
{Type.2, MyStatic2}
};
}
// Client Code
class ClientCode
{
void Start()
{
StaticMap.dictionary[Type.1].Do();
}
}
There are some fundamental reasons why you can't do that directly:
Static method calls are bound at compile-time
Static calls are not inherited - they are tied to the class that defines them
There is no implicit base type (and therefore no polymorphism) between static methods, even if the name, inputs, and outputs are all the same
Since your signature is the same for every static method, you could store a Action in the dictionary instead:
static Dictionary<Type,Action> dictionary = new Dictionary<Type,Action>
{
{Type.1, MyStatic.Do}
{Type.2, MyStatic2.Do}
};
then you can call the Action directly:
void Start()
{
StaticMap.dictionary[Type.1]();
}
It's slightly repetetive because you have to specify the method name in the dictionary as well, but it's type safe.
A key question is whether you want to call a single method on each type or whether you need to call multiple methods belonging to each type.
If it's just a single method, then what D Stanley suggested is the answer. If you store a number of Actions, each representing a method with the same signature on a different static class, then you're accomplishing what you said.
However that raises a question - why the constraint that each method must belong to a separate static class? This approach would work just as well if some or all of the methods belonged to the same class.
If you need to call more than one method from each class then an Action no longer works. You'd have to store collections of Action, which a) means class instances, and b) is a lot more complicated than just using interfaces and class instances.
One way to manage instances is by using a dependency injection container to create class instances for you. Using that approach, you can create non-static classes without having to go through the hassle of explicitly making them singletons. But you can tell the container to only produce one of each and reuse it. For example, using Castle Windsor:
container.Register(Component.For<ISomeInterface,SomeClass>));
Now every time the container is asked to provide an instance of ISomeInterface it will always provide the same instance of SomeClass.
Because the dependency you're looking for varies by type (Dictionary<Type, Something>) it sounds like what you're looking for might be related to generics. But it would be necessary to take a step back from the smaller problem and understand a slightly larger picture of what you're trying to accomplish.
Instead of having the entire class as static, create a Singleton instance.
public class Foo
{
public static Foo _Foo;
public Foo()
{
_Foo = this;
}
}
Then you may add it to your list, and also inherit from Interfaces, etc.
Sorry if the question sounds confusing. What I mean is that if I have a class that has a method that does a bunch of calculations and then returns a value, I can either make that method public (which gives my other classes access), or I can make it private and make a public get method.
Something like this:
public publicmethod{
return privatemethod();
}
private privatemethod{
//do stuff
return value;
}
Is this a futile exercise or does it provide additional program security?
Well, there is no additional security here. However, such a usage can sometimes make sense.
For example, the private and public method may have different semantics.
// base class
public virtual BuyFood()
{
BuyPizza();
BuyCoke();
}
private void BuyPizza()
{
// ...
}
// derived class
public override void BuyFood()
{
BuyChopSuey();
}
private void BuyChopSuey()
{
// ...
}
So your implementation is just calling to a private method -- but what is important, you expose the semantics: your BuyFood operation is just BuyChopSuey(). Your code says: "in this class, buying food is just buying chop suey" in a clear way. You are able to add BuyTsingtaoBeer() into BuyFood() any time without changing the semantics of the both methods.
It is completely redundant. It does not provide anything except another name for the same thing and another indirection for readers to follow. Simply make a single implementation, and make it public. On the same note, getX() { return x; } setX(T newX) { x = newX; } does not encapsulate anything, at best it's future-proofing.
You may end up implementing a particular function required by an interface in a single line, largely delegating to (possibly private) methods which exist for other good reasons. This is different, and more justified (but again, if it's only return someMethod(); you should probably abolish the private implementation and assume the common name). A particular case if when you need two implement two methods which do the same thing (e.g. from separate interfaces).
I think either way is fine, it's more a matter of style assuming the method doesn't change the state of the class. If you have a class that has a bunch of properties and very few methods, it probably makes more sense to define another property. If you have a lot of methods in the class but few properties, then a method is more consistent with your overall class design.
If the method changes a bunch of other class variables than I'd expose it as a public method instead of a property.
I don't think either way, property or method, is necessarily more secure. It depends on what checks you do - is the caller allowed to perform the calculation? Are all variables used in the calculations within acceptable ranges? Etc. All of these checks can be performed whether you are using a property or a method.
Well, actually the question is What code do I want to be able to call this method?
Any code in general, even from other assemblies? Make the method public.
Any code from the same assembly? Make it internal.
Only code from this class? Make it private.
Having a private method directly aliased to a public method only makes the private method callable from the outside, which contradicts its private status.
If the method only does some calculation and doesn't use or change anything in the object, make it a public static method:
public static CalculationMethod(int input) {
//do stuff
return value;
}
That way any code can use the method without having the create an instance of the class:
int result = ClassName.CalculationMethod(42);
Instead of public consider internal, which would give access only to code in the same assembly.
I am developing C# and asp.net web application.
I have general class called utilities, I have lot of public and static variables in this public utilities class.
Since this number is gradually increasing, I want to know is it good practice to store utilities methods and variable as public static.
Example of my code
public class utilities
{
public static string utilVariable1 = "Myvalue";
public static string utilVariable2 = "Myvalue";
public static string utilVariable3 = "Myvalue";
:
public static string utilVariableN = "Myvalue";
public static string UtilMethod1()
{
//do something
}
public static string UtilMethod2()
{
//do something
}
public static string UtilMethodN()
{
//do something
}
}
There's nothing inherently wrong with static classes, although they should typically not have state (fields). Your use of public static fields indicates that this is not the case, so it seems like you are using abusing the static keyword slightly. If your class needs to have state, then it should be a normal, non-static class, and you should create instances of it. Otherwise, the only public fields visible on the class should be const (consider the Math class, with constants such as Math.PI - a good use of static methods and fields).
Another consideration is cohesion. Methods typically exist grouped in one class because they are closely related in one way or another. Again, the Math class is a good example; everything in there has to do with maths. At some point, you would want to split your global utility class into multiple smaller, more focussed ones. See Wikipedia for some examples on cohesion, it sounds like your usage falls under "Coincidental cohesion (worst)".
There's nothing wrong with this approach for methods, but variables should really be const if they're going to be static and public. If they are subject to change then you should look at a different structure for variables that are being manipulated by more than one component.
Personally, I'm a fan of the Singleton pattern.
static is not a bad thing per se. Methods that don't need to access any member variables or methods should always be declared static. That way the reader of the code sees immediately that a method won't change member variables or methods.
For variables the situation is different, you should avoid static variables unless you make them const. Public static variables are globally accessible and can easily raise issues if multiple threads access the same variable without proper synchronization.
It is hard to tell for your case if it's a good or a bad idea to use statics, because you didn't provide any context information.
Creating one class to do it all is not a good practice, and it's recommended to structure your project, and keep stuff that belongs to each other separated from the randomness.
A great example of this was a project I took over from a co-worker. There was 1 class, called Methods. It contained over 10K lines of methods.
I then categorized them into approx. 20 files, and the structure was restored.
Most of the methods from that project were validating user input, which can easily be moved into a static class Validation.
One awful thing I notice is the mutable public and static variables. This is bad for several reasons:
Incorrect behavior, because if some method changes this, while it isn't supposed to do that, it causes other methods to behave improperly, and it's really hard to track down/debug.
Concurrency, how are we going to ensure thread safety? Do we let it over to all methods that work with that? Say if it's a value type, what will we let them lock on? What if some method forgets to make it thread safe?
Expand-ability (I hope you understand what I mean with that), if you have for example a static class data that stores all these public static variables, that you shouldn't have. It can store that once, if for example you might change your application structure a bit, and say want to make it possible to load two projects in the same screen, then it's very difficult to make that possible, because you can't create two instances of a static class. There is only one class, and it'll remain like that.
For number 3 a cleaner solution would be to store either a list of instances of a data class, or to store a reference to the default and/or active data class.
Static member, and private static members (or protected) are a good practice, as long as you don't make huge classes, and the methods are related.
Public and static variables are okay if they're not really variable.
The two ways to do this is by marking them constant (const modifier) or readonly (readonly modifier).
Example:
public class UtilitiesClass
{
internal UtilitiesClass() { }
public void UtilityMethod1()
{
// Do something
}
}
// Method 1 (readonly):
public static readonly UtilitiesClass Utilities = new UtilitiesClass();
// Method 2 (property):
private static UtilitiesClass _utilities = new UtilitiesClass();
public static UtilitiesClass Utilities
{
get { return _utilities; }
private set { _utilities = value; }
}
The advantage of method 1 is that you don't have to worry about thread-safety at all, the value can't change.
Method 2 is not thread-safe (though it's not difficult to make it that), but it has the advantage of allowing the static class itself to change the reference to the utilities class.
No, it is not a good practice for large applications, especially not if your static variables are mutable, as they are then effectively global variables, a code smell which Object Oriented Programming was supposed to "solve".
At the very least start by grouping your methods into smaller classes with associated functionality - the Util name indicates nothing about the purpose of your methods and smells of an incoherent class in itself.
Second, you should always consider if a method is better implemented as a (non-static) method on the same object where the data that is passed as argument(s) to the method lives.
Finally, if your application is quite large and/or complex, you can consider solutions such as an Inversion of Control container, which can reduce the dependency on global state. However, ASP.Net webforms is notoriously hard to integrate into such an environment, as the framework is very tightly coupled in itself.
I just finished coding a class, and realized that all of its public functionality is encapsulated in a single method. It has no properties, no shared resources, and requires no constructor overload and handles disposal of anything it uses. It looks something like this:
public class ReportGenerator
{
public string GenerateReport(List<SomeClass> stuffToReportOn)
{
string fileName = String.Empty;
using(var reportDs = CreateDataSet(stuffToReportOn))
{
//do the stuff with the third party tool that
//creates the report.
//Construct the filename.
//Save the report.
}
return fileName;
}
private TypedDataSetRequiredByThirdPartyLib CreateDataSet(List<SomeClass> reportItems)
{
//create the dataset, calling two other private methods
//to build the tables/rows
}
}
After I finished refactoring it, I realized that this class could be entirely static. My question is, should it? Should a class that encapsulates all of its functionality in one public method be made static?
No. and what are the expected benefits?
Far more important is the potential for errors. If in your class you declare a static variable, it'll only get initialised once, its value will persist and each call will potentially behave differently. Easily over-looked, this can be difficult to debug.
No, it will make writing unit tests for this class - or classes that use this class - impossible.
With a tool like FakeItEasy, you don't even need the class to implement an interface to be able to mock it (which means you can get started quickly mocking an old code base that wasn't written with TDD in mind), but it can't get around static calls.
UPDATE
Lets say you need to unit test a method GenerateWidgetReports that calls ReportGenerator.GenerateReport. You need to ensure stuffToReportOn contains only Widget1 & Widget2. How do you code that test?
What you end up doing is having GenerateWidgetReports use a method called GetStuffToReportOn, you can test that, fine. GenerateWidgetReports then just becomes glue that calls GetStuffToReportOn and passes it's result to ReportGenerator.GenerateReport.
However you still have no test for GenerateWidgetReports, because you can't call it without actually generating the report.
Ideally the class with GenerateWidgetReports takes an IReportGenerator object, you mock the GenerateReport method and test in there for Widget1 & Widget2.
You can't do any of this with any Mocking tool if GenerateReport is static.
Update 2
I stand corrected, TypeMock can intercept and re-direct calls to static methods. See this answer
Other than difficulty in unit testing, you should ask yourself:
Do I make changes to the parameters? If so, how often?
Does the object need to have a state?
Do I need to keep the object around after the process?
If you determine that making it a static class works for you, you could also decide to go one step further and make an extension method:
public static class ReportExtension
{
public static string GenerateReport(this List<SomeClass> stuffToReportOn)
{
string fileName = String.Empty;
using(var reportDs = CreateDataSet(stuffToReportOn))
{
//do the stuff with the third party tool that
//creates the report.
//Construct the filename.
//Save the report.
}
return fileName;
}
private static TypedDataSetRequiredByThirdPartyLib CreateDataSet(List<SomeClass> reportItems)
{
//create the dataset, calling two other private methods
//to build the tables/rows
}
}
Pretty sure I have my formatting correct for an extension method.
Edit:
You still have the issues of unit testing because code depends on this static method. Ultimately, you will have to decide on the pros and cons and make the decision yourself. I could be wrong, but if you were to unit test the dependent code with this as an instance class, you can gain some confidence that it should be fine as a static or extension method.
Yes, it would make using your class a lot easier.
Scenario. Language C#, Unit testing using VS2008 Unit testing framework
I have a static class with a static constructor and 2 methods.
I have 4 test methods written to test the entire class.
My Static Constructor has some important initializations.
Now if I run all the 4 unit test cases in tandem, the static constructor will be
called only at the beginning. At the end of each test case, there is no such thing
called static destructor, So the state info in the constructor gets carried to the
next unit test case also. What is the workaround for this.
Type staticType = typeof(StaticClassName);
ConstructorInfo ci = staticType.TypeInitializer;
object[] parameters = new object[0];
ci.Invoke(null, parameters);
from http://colinmackay.scot/2007/06/16/unit-testing-a-static-class/
The simplest solution is to add a "Reset" method to your static class, which would have the equivalent behaviour of destructing it and reconstructing it.
There may be a valid reason why you are using a static class here. However, because statics don't play nicely with unit tests, I usually search for an alternative design.
I would move the initialization from the static constructor to a method that is called by the constructor. By making this method internal, you can then call this method from your tests to reinitialize the class.
public static class MyClass
{
public static MyClass()
{
initialize();
}
internal static void initialize()
{
// Do initialization (and cleanup if necessary)
}
public static void Method1() {}
public static void Method2() {}
}
In order to call the internal methods you need to use the InternalsVisibleTo attribute, as described in this blog.
You can also make it private, but then you need to use reflection to call it.
But as Andrew Shepherd said, you should also check if a static class is the best design of this class.
With out knowing the usage of the class commenting on just the usage is of cause a bit tricky but ill give it a go anyways. To me the above sounds like a smell more than a testing problem.
A static class (just as singletons) are basically a collection of global functions/variables which generally is a bad thing in oop. I'd say trying to test the test issue is (eventhough probably the easiest right now) only fixing the symptom but not the problem.
I'd suggest to take a look at the desing a concidere if you really need the static class or if it just seemed like the easiest way to fix a problem at the time
For the sake of completeness, if you need to reset a non-public field/variable of a static class, it is also possible to do so via reflection.
using System.Reflection; // or Mono.Reflection
public static class MyClass{
private static string myString;
}
var newValue = "Potatoes";
var field = typeof(MyClass).GetField("myString", BindingFlags.Static | BindingFlags.NonPublic);
field.SetValue(null, newValue); // the first null is because the class is static, the second is the new value
Well, you didn't specify which language you were using, but if there is a way to open up your static class from within the test file, then I would add a fake destructor to it, which you can call after each test. That way, the 'destructor' stays in the test class, and out of your production code.
You could use Typemock's Isolator which is capable of mocking static classes, so in each test you can "define" how the static will be operating.
It's not a free product though.
It sounds like you're trying to test the static constructor. This seems like a bad idea.
Consider extracting the initialization logic into a separate (non-static) class instead.
For the sake of discussion, let's say your static class is called MySingleton, and let's say you create a new class called MyInitializer, with an Execute method. MySingleton's static constructor could instantiate MyInitializer and call Execute, which does all the initialization.
Then your production code could use MySingleton, and ignore MyInitializer. Your tests, on the other hand, could ignore MySingleton, and merrily create a new MyInitializer instance for each test, getting a fresh start each time.