I have a test that looks like following:
[Test]
public void LoggerTest()
{
var log = Substitute.For<Logger>();
log.DidNotReceiveWithAnyArgs().Info("");
log.ReceivedWithAnyArgs().Info("");
}
The test succeeds, which it obviously shouldn't. To my best knowledge this is the syntax according to the NSubstitue website.
Can anybody tell me where the problem lies?
I use NSubstitue in version 1.7.2.0 from the NuGet package manager.
NLog.Logger is a concrete class with non-virtual members, so NSubstitute will not be able work with it (see the note on Creating a substitute).
If you need to test logging one option is to wrap the log functionality in your own, app-specific interface. This makes it easier to substitute in a new logger for testing purposes (can use NSubstitute or other mocking library, or hand-code your own TestLogger tailored for your test purposes).
Related
The AWS SDK can locate API call interceptors via classpath scanning (looking for software/amazon/awssdk/global/handlers/execution.interceptors and instantiating classes specified there).
I'm writing a Java Agent with the intention of causing my interceptors to be locatable by the AWS SDK.
My interceptor is bundled with the Java Agent.
My interceptor implements AWS's ExecutionInterceptor.
The AWS SDK is not bundled with my agent, because I'd like the end-user to provide their own AWS SDK version.
For regular standalone applications, this is a no-brainer, as the Java Agent is automatically added to the runtime classpath of the application. The AWS SDK finds my interceptors with no problem.
However, this approach completely breaks with Spring Boot applications where the AWS SDK is bundled as a dependency under BOOT-INF/lib. The reason boils down to Spring Boot's classloading hierarchy. My interceptor class can be found, but its loading fails due to inability to find AWS's ExecutionInterceptor, as it is loaded in a "lower" classloader in the hierarchy.
So I figured that my approach should be to somehow modify Spring Boot's classloader search. However, I'm facing these issues:
At the time of the agent being called, Spring Boot's "lower" classloader isn't created yet.
I am not entirely sure what it is that I need to instrument.
I've read of Byte Buddy being able to help in such "interesting" circumstances but haven't found a way to make this work yet. Any ideas?
(EDIT: I'm looking for a solution that doesn't require code/packaging changes, hence the Java Agent approach)
(EDIT: Things I've tried)
Following Rafael's answer: The method in the SDK that resolves all interceptors is in the class SdkDefaultClientBuilder, and is called resolveExecutionInterceptors.
The following, then, works for standalone JARs which are not SpringBoot applications:
public static void installAgent(Instrumentation inst) {
new AgentBuilder.Default()
.with(RedefinitionStrategy.DISABLED)
.type(ElementMatchers.nameEndsWith("SdkDefaultClientBuilder"))
.transform(
new Transformer() {
#Override
public Builder<?> transform(Builder<?> builder, TypeDescription typeDescription,
ClassLoader classLoader, JavaModule module) {
return builder.visit(Advice.to(MyAdvice.class).on(ElementMatchers.named("resolveExecutionInterceptors")));
}
}
).installOn(inst);
}
For SpringBoot applications, however, it looks like the advice isn't applied at all. I am guessing that this is because the SdkDefaultClientBuilder type isn't even available at the time when the agent starts. It is available during SpringBoot's runtime, in a different classloader.
Byte Buddy allows you to inject code in any method of any class, so the first and only major thing you would need to find out would be where your interceptor is instantiated. This can typically be done by setting a breakpoint in the constructor of the interceptor in the working scenario and investigating the methods in the stack. Find out where the classes are discovered, for example the method where software/amazon/awssdk/global/handlers/execution.interceptors is read.
Once you have identified this method, you would need to find a way to manually extract the interceptors defined by your agent and to manually add them. For example, if the file-extracted interceptors are added to an argument of type List<Interceptor>, you could use Byte Buddy to modify this method to also add those of your agent.
Normally, you use Byte Buddy's AgentBuilder in conjunction with Advice to do so. Advice let's you inline code into another method as for example, assuming you find a method with an argument of type List<Interceptor>:
class MyAdvice {
#Advice.OnMethodEnter
static void enter(#Advice.Argument(0) List<Interceptor> interceptors) {
interceptors.addAll(MyAgent.loadMyInterceptors());
}
}
You can now inline this code into the method in question by:
class MyAgent {
public static void premain(String arg, Instrumentation inst) {
new AgentBuilder.Default().type(...).transform((builder, ...) -> builder
.visit(Advice.to(MyAdvice.class).on(...))).install(inst);
}
}
You might need to use AgentBuilder.Transformer.ForAdvice if the classes in question are not available on the agent's class loader where Byte Buddy resolves the advice using both the target and the agent class loader.
I have started using Specflow 3.0 for .NET core tests project with built-in MSTest runner.
I encountered problem while trying to setup one-time method execution in order to persist bearer token value for all running tests in Specflow.
So my idea was to create [BeforeTestRun] Hook static method which would make HTTP request with given credentials. The problem is that those credentials are stored in .runsettings file, so I need to have MSTest's TestContext object in order to access dictionary property.
In Scenario's I'm injecting TestContext and it works fine, however I do not know how to access this object in static [BeforeTestRun] method. Is there any chance to create this object myself and store in static property?
As you see this is abstract class, so I guess Test Framework is automatically injecting concrete implementation in Scanarios with DI. How could I get this concrete implementation?
If solution is not present, would you suggest another approach how could I store configurable settings besides .runsettings so I could access them in static [BeforeTestRun] method without DI?
Thank you
AFAIK I know the behaviour of TestContext in MSTest, you get in plain MSTest for every test your own instance of TestContext.
So you can't get an instance for the whole testrun.
What you could do is, that you do the HTTP request in the BeforeScenario hook of the first scenario that gets executed. There you can get to the TestContext instance without problems.
Is there an easy way to evaluate that the dependencies are available within the DI container for either a given service or all services? (Specifically at build time)
I have a couple of Azure Functions running that I manually build the DI container for to keep the content to a minimum and when the dependency tree changes I have to remember to add the new dependency to the function. If I don't I get an error when the function executes the first time not when I build it to republish.
Is there a best practice to follow with this? Can it be achieved with some sort of unit test?
I don't think there is a way to validate this at build time, but as you suggest, you could verify this with a unit test if you follow the usual extension approach to registering your services. Arrange the list of types that should be registered, call your reg extensions, and validate the contents. The only thing I don't think you can do is confirm they're registered with the correct lifetime.
public static IServiceCollection AddFunctionsServices(this IServiceCollection services)
{
return services
.AddTransient<Foo>()
.AddTransient<Bar>()
.AddTransient<Baz>();
}
[Fact]
public void RegisteredServices()
{
var types = new List<Type>{ typeof(Foo), typeof(Bar), typeof(Baz) };
var provider = new ServiceCollection()
.AddFunctionsServices()
.AddSomeOtherServices()
.BuildServiceProvider();
foreach(var t in types)
Assert.NotNull(provider.GetService<t>());
}
If registration happens in a separate library used by different apps (I actually do this myself with a library that supports Functions, web apps, and command-line utilities), you can easily set up different tests for the list of services required by each library consumer.
It looks like mentioned annotations are executed inside the deployment. I need them to be run outside, let's say to start some simulator class on startup and stop it on the end. How can I do it? The simulator uses socket communication and it should not be started inside the server.
How to mix arquillian with "plain" junit(not executed in container).
You can use the arquillian #RunAsClient annotation combined with the junit #BeforeClass and #AfterClass:
#BeforeClass
#RunAsClient // runs as client
public static void shouldBeAbleToRunOnClientSideBeforeRemoteTest() throws Exception {
System.out.println("before!!");
}
#AfterClass
#RunAsClient // runs as client
public static void shouldBeAbleToRunOnClientSideAfterRemoteTest() throws Exception {
System.out.println("after!!");
}
The answer that Franck gives will certainly work, and will probably be what most users will want to use. If, however, you need to get some more detail about what's going on, or need some more control you can certainly hook into the Arquillian life cycle and register observers for all sorts of events that Arquillian emits. Unfortunately, it isn't as easy as listening to a CDI event.
You'll need to create a services entry in META-INF/services with the file name of org.jboss.arquillian.core.spi.LoadableExtension. The contents of that file will be the Fully Qualified Name (FQN) of the classes that implement the LoadableExtension interface from Arquillian. You can then in the register(ExtensionBuilder) method register any classes that will observe events. Those classes will simply need a public void methodName(#Observes EventType) method for all the events they want to listen for. The #Observes annotation is in the org.jboss.arquillian.core.api.annotation package.
You can see this in action the Arquillian Recorder Reporter extension here, here, and here. I understand this is probably more than what most people will want to do, but again, if you need the power and hooks, Arquillian should be able to give you what you need.
I'm using custom asp.net membership provider with underlaying nhibernate data access code, which is fine. Now I need to exercise these methods using tests.
Anyone interested in suggesting how these methods should be tested? with providing some links explaining test methods using some standars maybe ?
This is my first question so be gentle :)
When it comes to unit testing any code that does something with the database or a 3rd party library you should de-couple these dependencies so that your tests only test your code.
For example, if we have a method in our membership provider for adding a single user, what we want to be testing is that our code for this single method works correctly and not that the database is up and running or that methods called by this method work. Our unit test should still pass even if the database is offline or if method calls on other classes fail.
This is where Mocking comes into play. You'll want to mock out your data context and set up any methods you'll be using on it so that you can control its response.
Look closely at the methods you have in your membership provider. What should each one do? That's the only thing you really want to test. Does this method, as a standalone unit, do the job I'm expecting it to.
Membership providers are pretty difficult to mock and test, so personally I don't bother. What I do however is place all my membership code in classes that are easily testable.
Most of my custom providers look something like this:
public class CustomMembershipProvider : MembershipProvider
{
private readonly IUserService _userService;
public ButlinsMembershipProvider()
{
_userService = DI.Resolve<IUserService>();
}
public override bool ValidateUser(string username, string password)
{
return _userService.Authenticate(username, password);
}
}
In this example, I would write integration tests to verify the behavior of the user service. I don't test the provider.