I have a class A with code and class ATest with tests: testcase1, testcase2... . I added new code to A and new testcaseN to ATest. During refactoring, I observed that class A is to big and could be split into two separate classes: A and B. Some test cases should be moved from ATest to newly created BTest.
Is there any method to do this automatically in Intellij to move selected methods and change access to remaining ATest class properties and help methods?
You can place the cursor on the method name, that you wish to move. Then select Refactor -> Move instance method.... There will be a wizard on what to do next for related instances, helper methods...
Related
Please take a look at my class. In it WoW avatars are created. In the constructor method instances of different classes are created. If the program is extended by a new class (e.g. Tauren), the constructor method must be changed stupidly. One would have to add another object instantiation into the method. This contradicts the Open Close principle, according to which a software should be open for extensions but closed for changes. How can I solve this problem.
public class UpdateAvatarFactory{
public UpdateAvatarFactory(Client client){
ICreateMethod createHuman = new CreateHuman();
createHuman.name="Human";
ICreateMethod createElf = new CreateElf();
createElf.name="Elf";
ICreateMethod createGnome = new CreateGnome();
createGnome.name="Gnome";
ICreateMethod createOrc = new CreateOrc();
createOrc.name="Orc";
client.avatarFactory.addCreateMethod(createHuman);
client.avatarFactory.addCreateMethod(createElf);
client.avatarFactory.addCreateMethod(createGnome);
client.avatarFactory.addCreateMethod(createOrc);
}
}
In case you depicted, there is no point of having such class at all - it is the same as a static method.
Avatar factory could be a private member of Client and could simply have a method which takes array of CreateWhatever (according to Law of Demeter).
Now how to prevent hardcoding all these new Create*()? In real world scenarios it is usually done by DI (dependency injection) libraries. They often comes with your framework of choice (e.g. Spring), but you can find standalone solutions too (I don't work with java for many years now, so I don't know the latest trends, but you can find them easily).
My requirement goes like this.
Log in to the application and open the System property menu to return a value of the property.
Open Another menu in the application and based on the value returned in the above step, perform the test scenario.
The problem is, for each #Test methods in the same class I need to perform both step 1 and 2 which is a time taking and unnecessary. The property retrieved from 'step 1' will be the same throughout the execution of the tests in the class.
Is there anyway I can execute 'step 1' just once at the start of the test and use the property value returned for all the #Test methods in the class following it?
P.S- I checked on the dependsOnMethods annotation and not sure whether it is a solution I am looking for.
If you're using JUnit, it sounds like #BeforeClass is what you are looking for. Method with this annotation runs only once per class and you can store any value returned in a global variable. Or, you might consider #Before annotation (runs before each test) if that suits you better.
Other testing frameworks use similar idea.
What's the difference between the child of a class and an instance of a class? Both seem to inherit code from their "parent". Is the difference that an instance of a class is executed code, versus a child of a class merely being around to create additional instances?
A class is nothing more than a definition, a template, a pattern. An instance of that class is a copy of that definition that has been allocated memory space in which to hold its data. It's like saying a cake is an instance of a cake recipe.
A child of a class is literally that - the parent forms a base definition, which the child then extends or enhances. It's a variation on the parent, much like a chocolate cake is a variation (or it extends) a basic cake recipe.
Note that this very simple explanation of OO concepts hides how this stuff is actually implemented at the machine level. A class can contain methods (operations) - there is only one copy kept of these methods, instantiating a new instance of the class doesn't make a fresh copy of the methods. Instead memory space is allocated to the new instance, and pointers will be used to point to the actual code that should be implemented for each method. Each instance does have its own copy of data (attributes) though.
For example with php:
class A {
//...
}
class B extends A {
//...
}
$a = new A();
We say B is the child of A, $a is an instance of A.
Is there a way to create a suite of test methods, not just test classes?
I'd like to put together a test suite that just runs particular tests methods from a test class. I don't see a way to do this from my limited junit knowledge and from searching the web.
Use Categories feature in JUnit4.
Example: if some methods scattered both in ATest and BTest are expected to executed :
//Define Categories
#RunWith(Categories.class)
#IncludeCategory(NeedTest.class)
#SuiteClasses({ ATest.class, BTest.class })
class MySuite{
...
}
Then in ATest and BTest, annotate your expect methods as:
#Test
#Category(NeedTest.class)
public void test()
When you run MySuite, only the methods annotated with #Category(NeedTest.class) will be executed. Of course, you could create multiple test categories,
ps: NeedTest.class is just a marker class, it can be any class.
I am using classes and static methods to 'scope' functions in a namespace, similar to C#. However, every time I add a new method to a class, at first it is not found. I have to restart the MATLAB environment (2007a) for the new methods to be recognised.
Surely there is an 'update' or 'refresh' type command that I can use so that I do not have to restart the MATLAB environment each time I add a function?
Issuing this call to CLEAR should do it:
clear classes
One unfortunate side effect of this is that it also effectively issues a clear all, which clears all of the variables in the workspace as well (however, this would happen anyway when you close and restart MATLAB). This clearing of the workspace actually serves a purpose, since it will remove any variables of the same type as the old version of your class, which potentially wouldn't work correctly with the new version of your class.
The function REHASH may work, but I doubt it (I think it deals more with file paths than class definitions).
Clearing instances of your class should work.
Suppose that you have an instance of "MyClass" in your base workspace:
foo = MyClass;
Now, suppose you edit MyClass and add new static method "bar":
foo.bar(); % Will cause error, as foo is instance of previous "MyClass"
However, "clear"-ing foo will remove the reference to the previous class:
clear('foo');
foo = MyClass;
foo.bar(); % this should now work.
This should be fine if you only have one or two instances of the class in your base workspace. If you have many instances of the class in your base workspace, then you may want to write a script to clear them:
varList = whos;
for iVar = 1:numel(varList)
if isequal( 'MyClass', varList(iVar).class )
clear( varlist(iVar).name );
end
end
clear('varList');
clear('MyClass');
If you have instances of the class in more locations, you may wish to extend the script as appropriate.
The last call to clear the class name might only be necessary if you are making modifications to classes in an inheritance hierarchy.
try "clear classname"