Can mockito or easymock replace rmock - easymock

I'm sitting with a legacy project, and we're starting to replace some old legacycode. As Rmock don't have support for junit4, we would like to replace it. One thing i was wondering is - how could i replace the dynamictestsuite feature of rmock. This is a good feature where you create a dynamic testsuite for each run, and can do stuff like.
#Override
protected void setupSuite() {
forEach(is.clazz.assignableTo(TestCase.class).and(is.not(is.clazz.name(is.endingWith("oldTest")))).perform(addAllToSuite);
}
that would get all testclasses not ending with oldTest and create a dynamictestsuite. And so on, you get the point.

ClasspathSuite can define a suite by searching for JUnit test classes in the class path, with a filter on the test class names to include or exclude.
import org.junit.extensions.cpsuite.ClasspathSuite.*;
import org.junit.runner.RunWith;
#RunWith(ClasspathSuite.class)
#ClassnameFilters({"!.*oldTest"})
public class MySuite {}

Related

NUnit: How can I set name of test depending on parametr in [TestFixture(typeof(param))]

I'm using NUnit + Webdriver + C#. Setup class has next stucture:
[TestFixture(typeof(InternetExplorerDriver))]
[TestFixture(typeof(ChromeDriver))]
public partial class SetupBase<TWebDriver> where TWebDriver : IWebDriver, new()
{
public IWebDriver _driver;
[OneTimeSetUp]
public void OneTimeSetUp()
{
Init();
}
}
How can I set name of tests to include methode name, arguments and name of browser?
I tried with capabilities but it didn't help
ChromeOptions options = new ChromeOptions();
options.AddAdditionalCapability("Name", String.Format ("{0}_Chrome", TestContext.CurrentContext.Test.Name), true);
Also tried to use next code but was not able to find way how to pass driver type to NameAttribute
public class NameAttribute : NUnitAttribute, IApplyToTest
{
public NameAttribute(string name)
{
Name = String.Format("{0} {1}", name);
}
public string Name { get; set; }
public void ApplyToTest(Test test)
{
test.Properties.Add("Name", Name);
}
}
Can you help me please. Maybe need to update base class structure somehow?
This is how I use in tests
public class _001_General<TWebDriver> : SetupBase<TWebDriver> where TWebDriver : IWebDriver, new()
{
[OneTimeSetUp]
public void OneTimeSetupTest ()
{
//somework
}
[Test]
public void Test ()
{
//somework
}
}
Also SetupBase class contains functions that are used in tests
In NUnit, test cases, test methods, test fixtures and generic test fixture classes are all "tests" even though we sometimes talk loosely about "tests" as meaning test cases.
In your example, the following names are created:
_001_General<TWebDriver> (or maybe _001_General<>)
_001_General<InternetExplorerDriver>
Test
_001_General<ChromeDriver>
Test
Tests also have "fullnames", similar to that for a type or method. For example
_001_General<ChromeDriver>.Test
(Note: the fullname would also include a namespace, which I haven't shown.)
If you are using a runner that displays fullnames, like the NUnit 3 Console Runner, then there is no problem. So, I assume you are not. :-)
Some runners, like the NUnit 3 Visual Studio Test Adapter use simple test case names. So you would end up with a bunch of tests displayed with the name "Test."
Is that your problem? If so, this is not much of an answer. :-) However, I'll leave it as partial and add to it after hearing what runner you want to use and what you would like to see displayed in it.
UPDATE:
Based on your comment, what you really want to see is the test FullName - just as it is displayed by the NUnit 3 Console runner that TC runs for you. You'd like to see them in the VS IDE using the NUnit 3 VS Adapter.
Unfortunately, you can't right now. :-) More on that below. Meanwhile, here are some workarounds:
Use the console runner on your desktop. It's not as visual but works quite well. It's how I frequently work. Steps:
Install the console runner. I recommend using Chocolatey to install it globally, allowign you to use it with all your projects.
Set up your project to run the console runner with any options you like.
Make sure you use an external console window so you get the color display options that make the console runner easier to use.
Size your windows so you can see everything (if you have enough screen space) or just let the console run pop up on top of VS.
Try to trick VS by setting the test name in a way that includes the driver parameters. That's what you are already doing and it sounds as if you have already gotten almost all you can out of this option, i.e. class name without class parameters. You could try to take it a step further by creating separate classes for each driver. This would multiply the number of classes you have, obviously, but doesn't have to duplicate the code. You could use inheritance from the generic classes to create a new class with only a header in each place where it's needed. Like...
public class TestXYZDriver : TestDriver ...
This might be a lot of work, so it really depends on how important it is to you to get visual results that include fixture parameters right now.
For the future, you could request that the NUnit 3 Adapter project give an option of listing tests by their full names. I haven't worked on that project for a few years, so I'm not sure if it's actually possible. It may not be entirely in the control of the adapter, since VS controls what is displayed.

Adding Allure #step annotation without specific method

I would like to create Allure step for specific code line and not per method, is it possible?I know that there is an Allure class with some helper methods but I can't figure out how to create a step.
You can do this by creating a separate class with Step method and call it everytime you want to add step info. For example:
import ru.yandex.qatools.allure.annotations.Step;
public final class LogUtil {
private LogUtil() {
}
#Step("{0}")
public static void log(final String message){
//intentionally empty
}
}
Above class contains the method for creating a step in allure. Now whenever you want to add step info in a test all you need to do is call this method like below:
LogUtil.log("Step information text");
You can find the detailed explanation here

solr: read stopword.txt in Custom Handler

I want to read stopword.txt in my custom handler. How to do that ? I know that this is used in Filtering and can be done from there. But I need to read that list in my Custom UpdateRequestProcessorFactory. Also can I read any other custom file created by me.
I was aware that limitation. I overlooked that you are using about update processor.
I looked into the code, here is an existing code you can use as example. SolrCoreAware is the interface you are after.
public class StatelessScriptUpdateProcessorFactory extends UpdateRequestProcessorFactory implements SolrCoreAware
#Override
public void inform(SolrCore core) {
resourceLoader = core.getResourceLoader();
}
Classes that implement org.apache.lucene.analysis.util.ResourceLoaderAware can read files under conf directory. However what it your use case anyway?
looks like xy problem

How to avoid that proguard obfuscates the classes annotated with #OnStart

In applications based on NetBeans Platform 7.2, it is possible to
replace the ModuleInstall classes with this code:
import org.openide.modules.OnStart;
import org.openide.modules.OnStop;
#OnStart
public final class Installer implements Runnable {
#Override
public void run() {
System.out.println("enable something...");
}
#OnStop
public static final class Down implements Runnable {
#Override
public void run() {
System.out.println("disable something...");
}
}
}
My problem is that, after obfuscation, the class loader does not find
the annotated classes.
In the Proguard configuration I added (as suggested here)
-keep #org.openide.modules.OnStart class *
But apparently this is not enough or it does not work.
Does anybody have a suggestion?
From I could figure out, you need to explicitly keep the annotations that you use to keep whatever specifications. So, in your case, adding
-keep enum org.openide.modules.OnStart
would allow this annotation to be used as a selector.
Proguard really ought to include a warning message if annotation selectors are not actually matching. It also doesn't really make sense to keep the annotation, especially if it's not of runtime retention.
Have you tried -keepattributes *Annotation*? It might do the trick, based on proguard usage.

Considerations when architecting an extensible application using MEF

I've begun experimenting with dependency injection (in particular, MEF) for one of my projects, which has a number of different extensibility points. I'm starting to get a feel for what I can do with MEF, but I'd like to hear from others who have more experience with the technology. A few specific cases:
My main use case at the moment is exposing various singleton-like services that my extensions make use of. My Framework assembly exposes service interfaces and my Engine assembly contains concrete implementations. This works well, but I may not want to allow all of my extensions to have access to all of my services. Is there a good way within MEF to limit which particular imports I allow a newly instantiated extension to resolve?
This particular application has extension objects that I repeatedly instantiate. I can import multiple types of Controllers and Machines, which are instantiated in different combinations for a Project. I couldn't find a good way to do this with MEF, so I'm doing my own type discovery and instantiation. Is there a good way to do this within MEF or other DI frameworks?
I welcome input on any other things to watch out for or surprising capabilities you've discovered that have changed the way you architect.
Is there a good way within MEF to
limit which particular imports I allow
a newly instantiated extension to
resolve?
Load the extension code in a separate container, and make sure that the restricted parts are not available in that container. Let's simplify the situation to these classes to construct an example:
[Export]
public class MyExtension
{
[Import]
public PublicService Service { get; set; }
}
[Export]
public class PublicService
{
}
[Export]
public class InternalService
{
}
[Export]
public class Program
{
[Import]
public MyExtension Extension { get; set; }
[Import]
public PublicService Service1 { get; set; }
[Import]
public InternalService Service2 { get; set; }
}
The goal is to allow MyExtension to import PublicService, but not InternalService. Internal code like Program should be able to import anything. You can achieve that like this:
var publicCatalog = new TypeCatalog(typeof(PublicService), typeof(MyExtension));
var publicContainer = new CompositionContainer(publicCatalog);
var internalCatalog = new TypeCatalog(typeof(Program), typeof(InternalService));
var internalContainer =
new CompositionContainer(internalCatalog, publicContainer);
var program = internalContainer.GetExport<Program>();
This code will not throw a composition exception. If you now change the import on MyExtension to the forbidden InternalService, you will get a composition exception as desired.
A side effect of this set-up is that PublicService cannot import any private services either, just like MyExtension. This kind of makes sense, because otherwise nothing would stop PublicService from exposing a private service via a property.
I have used TypeCatalog for the example, but in practice you should probably use something like the FilteredCatalog sample.
This particular application has
extension objects that I repeatedly
instantiate. I can import multiple
types of Controllers and Machines,
which are instantiated in different
combinations for a Project. I couldn't
find a good way to do this with MEF,
so I'm doing my own type discovery and
instantiation. Is there a good way to
do this within MEF or other DI
frameworks?
You might just be after the PartCreationPolicy attribute, which controls whether a part is shared (as in, created only once per container) or instantiated multiple times for each import. You can also specify the RequiredCreationPolicy parameter in an import attribute.
If that doesn't solve your problem, take a look at the PartCreator sample in the MEF sources (though note that it will probably soon be renamed to ExportFactory, it already has been in the silverlight edition of MEF).

Resources