In API Manager distribution we see "org.mozilla.javascript" (/repository/components/plugins/js_1.7.0.R4wso2v1.jar)
We believe this is actually Mozilla Rhino project.
We see also rhino.wso2 in POM.xml
I see in GitHub: github.com/mozilla/rhino, but I assume WSO2 forked the code base and maintains a different repository.
What is the actual repository for Rhino version that is being consumed in WSO2 API manager?
We see: http://maven.wso2.org/nexus/content/groups/public/org/mozilla/rhino/1.7R4/ and also http://maven.wso2.org/nexus/content/groups/wso2-public/rhino/wso2/js/1.7.0.R4.wso2v1/
What is the actual macen repro in use?
What is actual license of the actual Rhino version?
I understand from the license file it is MPL10
In maven.wso2.org/nexus/content/groups/public/org/mozilla/rhino/1.7R4/
we see the license MPL 2.0
developer.mozilla.org/en-US/docs/Mozilla/Projects/Rhino/License specifies it differently
You can programmatically query the underlying Rhino implementation to return the Rhino version, see here: http://nimbleapi.com/2016/05/javascript-getting-the-rhino-version/. Not sure if this will assist you to determine the repository or licence. Good luck!
Here is an excerpt:
// importPackage to get access to the required libraries,
// see https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Rhino/Scripting_Java
importPackage(Packages.org.mozilla.javascript);
var myContext = Context
var currentContext = myContext.getCurrentContext()
var rhinoVersion = currentContext.getImplementationVersion()
// Set the messagePayload to the rhino version in JSON format
var myPayload = { "rhinoVersion": rhinoVersion }
mc.setPayloadJSON(myPayload)
Related
I'm running into a few issues when trying to unit test HTTP Trigger Azure Functions in Visual Studio. I've created a GitHub repo (https://github.com/ericdboyd/TestingAzureFunctions) with an example solution that contains both an Azure Function project and a Unit Test project that demonstrates the issues.
First, when I bring in Microsoft.AspNet.WebApi.Core it creates a conflict between System.Web.Http and Microsoft.AspNetCore.Mvc.WebApiCompatShim when trying to use IContentNegotiator. The only way around that was to alias WebApiCompatShim in the csproj file for the test project using the following:
<Target Name="ChangeAliasesOfStrongNameAssemblies" BeforeTargets="FindReferenceAssembliesForReferences;ResolveReferences">
<ItemGroup>
<ReferencePath Condition="'%(FileName)' == 'Microsoft.AspNetCore.Mvc.WebApiCompatShim'">
<Aliases>webapicompatshim</Aliases>
</ReferencePath>
</ItemGroup>
Once I got past that error, I run into this issue which I haven't been able to get past. Using the HttpRequestMessage.CreateResponse extension method to return a response in the Azure Function, I get "No service for type 'System.Net.Http.Formatting.IContentNegotiator' has been registered." when I try to test it. I have tried to build a HttpRequestMessage that I think should work with that extension method using the following code which can also be found in the GitHub repo, but it fails, and I have worked on trying to get past this for several hours now.
IServiceCollection services = new ServiceCollection();
services.AddOptions();
services.AddSingleton(typeof(IContentNegotiator), typeof(DefaultContentNegotiator));
IServiceProvider serviceProvider = services.BuildServiceProvider();
var httpContext = new DefaultHttpContext {RequestServices = serviceProvider};
var httpConfiguration = new HttpConfiguration();
HttpRequestMessage request = new HttpRequestMessage
{
Method = HttpMethod.Post,
RequestUri = new Uri(url),
Content = new StringContent(content, Encoding.UTF8, "application/json"),
Properties =
{
{ HttpPropertyKeys.HttpConfigurationKey, httpConfiguration },
{ nameof(HttpContext), httpContext}
}
};
If I don't use that CreateResponse extension method, and just create HttpResponseMessage objects, it works fine.
Just to set some additional context, I know this is not the best way to unit test the code being executed by the Azure Function. I'm unit testing that code much more granularly. But I want to be able to unit test the Azure Function that is performing the mapping between the http request and response to that logic.
There are two Azure Functions and two unit tests in the GitHub repo, one set with the extension method, one without to demonstrate the issue. But everything else is the same.
Not a direct answer to your problem, but it should help you go forward.
You are using Azure Functions v2 - .NET Standard version. This version is currently in beta, so it's a bit shady territory: the documentation is missing and some issues exist.
In V2 you are advised to use HttpRequest class and IActionResult instead of 'classic' HttpRequestMessage and HttpResponseMessage. The default template has a signature like this:
public static IActionResult Run(
[HttpTrigger(AuthorizationLevel.Function, "get")] HttpRequest req, TraceWriter log)
This should enable you to get rid of your shim and to unit test the functions similar to ASP.NET Core way.
Specify the jsonformatter while responding as below
req.CreateResponse(HttpStatusCode.OK, $"Hello, {name}", new JsonMediaTypeFormatter())
I have an application which writes to App INsights using custom traces/metrics and also using REST API for reading data on to dashboard.
My questions is for my unit testing can I mock both custom traces(TelemetryClient) and REST API?
I see REST API has a DEMO version but provides random information. It would be helpful if i could setup a DEMO instrumentation key to write to and read from it for unit testing. Let me know.
My proffered approach would be (as for any external component) to create some sort of wrapper around Telemetry Client and then it would be easy to mock it or replace it later if needed.
The other approach I would try is to use TelemetryClient constructor overload with TelemetryConfiguration and mock TelemetryChannel.
var client = new TelemetryClient(
new TelemetryConfiguration
{
TelemetryChannel = new MOCK...
});
Application Insights has an example of mocking TelemetryClient by using a StubTelemetryChannel.
var configuration = new TelemetryConfiguration();
this.sendItems = new List<ITelemetry>();
configuration.TelemetryChannel = new StubTelemetryChannel { OnSend = item => this.sendItems.Add(item) };
configuration.InstrumentationKey = Guid.NewGuid().ToString();
configuration.TelemetryInitializers.Add(new OperationCorrelationTelemetryInitializer());
this.telemetryClient = new TelemetryClient(configuration);
Instead of mocking things out, it might be better to go with your second idea and actually create another application insights resource, and use the instrumentation key for that resource in the unit tests. there's a blog post with information about using multiple environments that should head you in the right direction.
I'd suggest you even do something like that for developer/debug builds as well, so that only your "production" telemetry goes to your real instance, and then all dev/test telemetry goes to another resource instead.
I am creating a cross-platform project with MvvmCross v3 and Xamarin solution and i would like to create some unit-tests.
This seems a bit outdated, so i was trying to follow this and it worked as expected.
However, I am now making an attempt to unit-test some of my domain services, which are dependent on platform specific MvvvCross plugins (e.g ResourceLoader).
Running the test results in the following exception:
Cirrious.CrossCore.Exceptions.MvxException: Failed to resolve type
Cirrious.CrossCore.Plugins.IMvxPluginManager.
I assume that IMvxPluginManager is probably registered in the Setup flow, and that I need to include platform implementation of the plugins in my project, yet I was wondering what would be the preferred way of setting up my unit-test project? Is there something that I am missing?
Is there any updated tutorial for the above task?
Are there already any plugin platform extensions that supports test environment, or should I make an attempt to write them by myself?
In general, you shouldn't be loading the plugins or a real MvxPluginManager during your service tests.
Instead your unit tests should be registering mock types for the interfaces that your services need to use.
var mock = new Mock<INeedToUse>();
// use mock.Setup methods
Ioc.RegisterSingleton<INeedToUse>(mock.Object);
// or you can use constructor dependency injection on INeedToUse instead
You can also register a mock IMvxPluginManager if you really need to, but in the majority of cases I don't believe you should need that. If you've got a case where you absolutely need it, please post a code sample - it's easier to talk in code than text.
This scenario should be well possible. I wanted to UnitTest my SqlLite service implementation. I did the following to get it to work:
Create a Visual Studio unit test project
Add a reference to .Core portable library project
Add a nuget reference To MvvmCross Test Helper
Add a nugget reference to MvvmCross SqlLite Plugin
( this will make use of the WPF implementation of SqlLite)
Download the SqlLite windows library and copy these into your test project
Sql Lite Download location
And make sure to add the sqllite3.dll to the root of your unit test project and set the "Copy to Output Library" to "Copy always". This will make sure the actual sqllite database is copied to the unit test dll location. (Check that the DLL is copied to your bin/debug folder)
Then write you unit test the following way:
[TestClass]
public class SqlServiceTests:MvxIoCSupportingTest
{
private readonly ISQLiteConnectionFactory _factory;
public SqlServiceTests()
{
base.ClearAll();
_factory = new MvxWpfSqLiteConnectionFactory();
Ioc.RegisterSingleton<ISQLiteConnectionFactory>(_factory);
}
[TestMethod]
public void YourSqlLiteTest()
{
// Arrange
var si = new SqlDataService(_factory);
var list = si.GetOrderList();
}
}
I haven't tested this with my viewmodel. By using the IoC.RegisterSingleton method the SqlConnectionFactory should be readyli available for your viewmodels.
I need to incorporate a pretty complex 3rd party web service into my Grails app. My plan was to use WSDL2Java to generate the stub classes from the wsdl, and this was the method recommended in the 3rd party's documentation (complete with examples). First i tried to use the Axis2 codegen plugin for Eclipse but eventually came up against an InvocationTargetexception. I debugged the plugin and found it was because the wsdl is defined with RPC encoding.
Some people have recommended using Axis 1.4 instead, so I've now installed that too but have come up against an IO Exception - Type {http://xml.apache.org/xml-soap}DataHandler is referenced but not defined.
Can anyone suggest a method for creating the java classes from this wsdl without having to hack the wsdl apart?
I ended up using the Axis2 wdsl2java and copying the required annotated code into the service and used the CXF plugin. I also put in my service the following code
static expose=['cxfjax']
The reason why I had to do this was because there was a "complicated" (for grails) structure my methods look like
#WebMethod(operationName = "authenticate", action = "http://betterhidethis/authenticate")
#WebResult(name = "authenticateResult", targetNamespace = "http:/betterhidethis/")
public ArrayOfString authenticate(
#WebParam(name = "strUserName", targetNamespace = "http://betterhidethis/")
String strUserName,
#WebParam(name = "strPassword", targetNamespace = "http://betterhidethis/")
String strPassword) {
Of cause the Geneerator also created the ArrayOfString class which I use later.
Hope this helps.
I've not seen anything in this area I would recommend to a client. If you've used Spring PortletMVC, how did you test it?
It's easy to test under the level of portlet code, and relatively easy to test on the client side through HtmlUnit, Selenium and the like, but I haven't seen anything that is a "Gray Box" test in the spirit of JSFUnit (which looks to me to be the way forward).
Apache's Pluto driver could theoretically be used to bootstrap a test harness. Has anyone tried this?
Any stub or data provider approaches?
Any approach to address two-phase processing concerns?
I don't know anything about portlets but here it goes.
There's portletUnit.
portletUnit is a testing framework
used to test JSR-168 portlets outside
portlet container just as servletUnit
is used to test servlets outside a
servlet container. The projected is
architected to map the functionally of
servletUnit onto portlets with
servletUnit itself providing the
foundation for portletUnit.
Some more related info could be found on his Project PortletUnit blog, including PortletUnit and Spring Portlet: Checking form validation errors.
When testing with portletUnit, it is
not obvious how to check if there were
any form errors. Fortunately, using
the render listener feature of
PortletRunner, there is a simple way
to check for validator errors.
There's also a blog article written by Nils-Helge Garli Hegvik in 2007 titled Testing Portlets with Jetty, Pluto and JWebUnit.
Remembering an excellent article from
Johannes Brodwall's blog about
integration testing with Jetty and
JWebUnit, I wanted to extend his
approach to use the embedded
jetty-pluto setup I have created. This
turned out to be to be quite easy.
Finally, Spring Framework documentation 10.2 Unit testing.
The
org.springframework.mock.web.portlet
package contains a set of Portlet API
mock objects, targeted at usage with
Spring's Portlet MVC framework.
[...] The org.springframework.test.web
package contains ModelAndViewAssert,
which can be used in combination with
any testing framework (e.g., JUnit 4+,
TestNG, etc.) for unit tests dealing
with Spring MVC ModelAndView objects.
[...] To test your Spring MVC Controllers, use
ModelAndViewAssert combined with
MockHttpServletRequest,
MockHttpSession, etc. from the
org.springframework.mock.web package.
Here's a related article written by John Ferguson Smart titled
Unit testing your Spring-MVC applications.
One of the great things about this
framework is how testable it is. In
Spring-MVC, any custom validators (for
field and form validation) and
property editors (for converting text
fields to specific Java types) are
dead-easy to test - you can just test
them as if they where isolated POJOs.
Spring-MVC also comes with a full set
of mock objects that you can use (with
a bit of practice) to test your
controllers to your heart's content.
For example, you can use classes like
MockHttpServletRequest and
MockHttpServletResponse to simulate
your HTTP request and response
objects. This is also made easier by
the fact that Controllers can be
instanciated as normal Java classes.
For example, imagine you are testing a
controller class for a page that
updates a client details record. You
could do this very simply as follows:
public class UpdateClientTest {
//
// Prepare your request
//
request.setMethod("POST");
request.setParameter("id", "100");
request.setParameter("firstName", "Jane");
request.setParameter("lastName", "Doe");
//
// Invoke the controller
//
controller = new ChoosePeriodController();
ModelAndView mav = controller.handleRequest(request, response);
//
// Inject any service objects you need
//
controller.setClientService(clientService);
...
//
// Inspect the results
//
assert mav != null;
assertEquals("displayClient",mav.getViewName());
Client client = (Client) mav.getModel().get("client");
assertEquals("Jane",client.getFirstName());
assertEquals("Doe",client.getLastName());
...
}
...
Checkout spring-test-portlet-mvc (https://github.com/markusf/spring-test-portlet-mvc), which exposes the features of MockMvc to the Portal context and lets you integration test your Spring Portlets easily.