A pretty common problem with any kind of integration test is getting the unit under test into a known state -- the state that sets up well for the test you want to perform. With a unit test, there's usually not much state, and the only issue is in potentially mocking out interactions with other classes.
On the other hand, when testing a whole app there's all sorts of potentially persistent state, and getting the app into a clean state, or trickier still, into a known state that isn't "clean" without any access to the app itself is a little tricky.
The only suggestion I've found is to embed any necessary setup in the app, and use something like an environment variable to trigger setup. That is, of course, viable, but it's not ideal. I don't really want to embed test code and test data in my final application if I can avoid it.
And then there's mocking out interactions with remote services. Again you can embed code (or even a framework) to do that, and trigger it with an environment variable, but again I don't love the idea of embedding stubbing code into the final app.
Suggestions? I haven't been able to find much, which makes me wonder if no-one is using Xcode UI testing, or is only using it for incredibly simple apps that don't have these kinds of issues.
Unfortunately, the two suggestions you mentioned are the only ones that are possible with Xcode UI Testing in its current state.
There is, however, one thing you can do to mitigate the risk of embedding test code in your production app. With the help of a few compiler flags you can ensure the specific code is only built when running on the simulator.
#if (arch(i386) || arch(x86_64)) && os(iOS)
class SeededHTTPClient: HTTPClientProtocol {
/// ... //
}
#endif
I'm in the middle of building something to make this a little easier. I'll report back when its ready for use.
Regarding setting up the state on the target app there's a solution. Both the test runner app and your app can read and write to the simulator /Library/Caches folder. Knowing that you can bundle fixture data in your test bundle, copy it to the /Library/Caches on setUp() and pass a launch argument to your application to use that fixture data.
This only requires minimal changes to your app. You only need to prepare it to handle this argument at startup and copy over everything to your app container.
If you want to read more about this, or how you can do the same when running on the device, I've actually written a post on it.
Regarding isolating your UI tests from the network, I think the best solution is to embed a web server on your test bundle and have your app connect to it (again you can use a launch argument parameterize your app). You can use Embassy for that.
Related
Is there a way to get the Firebase Function url from the Admin SDK for nodejs?
In prod it will look like: https://REGION-PROJECT.cloudfunctions.net/FUNCTION_NAME
And when serving locally: http://localhost:PORT/PROJECT/REGION/FUNCTION_NAME
Is it possible to get this value in nodejs programmatically? E.g. from admin or configuration settings?
The Firebase Admin SDK doesn't expose any APIs that deal with Cloud Functions. From what you've shared, it sounds like you have everything you need to build the URL yourself, which is the right way to go.
If you really must use another piece of software, you'll have to dive very deep into the inner workings of the Firebase CLI and figure out how to reuse its code. You'll probably have to look in two places - one for the emulator, and another for deployment. I suspect this is almost certainly not going to be worth your time, since building the strings yourself is pretty straightforward.
Since you don't say exactly what you want to accomplish, I'll just guess that you want your app to be aware of when you're in development vs. production mode.
What I did was to simply write in some checks in my front- and back-end code. For instance, in the browser/web code:
if (window.location.href.toString().includes('localhost:5000')) {
// exhibit desired behavior for emulator
} else {
// exhibit desired behavior for production
}
Depending on how you're calling your node/backend functions, you could pass along the execution context (emulated or production), and use that in the back, too.
It's not perfect, but it's actually streamlined development for me quite a bit. Hope that helps!
I've found myself in an interesting position. I currently use the latest Unity container, I'm on asp.net core 2.2, and I use application insights. As such, I have configured DI in my web app to use unity instead of the out of the box DI provider in core. I also use Application Insights and use the IWebHostBuilder.UseApplicationInsights extension to spin up AI for my app.
With all this in mind, I have a piece of code whose constructor takes in IHttpContextAccessor so I can access the HttpContext. It was working great. Then, I had another small app that I was trying to reuse the functionality, and the HttpContext was null coming from IHttpContextAccessor. With a bunch of guess, test, revise, I found that IWebHostBuilder.UseApplicationInsights seems to initialize that Request property (HttpContext) on IHttpContextAccessor. If I commented out that AI extension, I would get null; uncomment it, it worked.
I've started to look through the AI code to figure out what exactly they're doing, but honestly, with all the dependencies and pipelines and all that, it's a pretty daunting task. I was hoping someone could point out where/how AI is doing this so my code doesn't NEED AI in order to work. All help would be incredibly awesome.
Use AddHttpContextAccessor extension to add it to DI. HttpContextAccessor is not added by default due to performance impact.
services.AddHttpContextAccessor();
After some struggle, and hoping this post would enlighten me on the AI ask, I found that I didn't need to replicate the AI mechanism, if there's even one at all.
Originally, I was accessing the IHttpContextAccessor via code in the view (Razor). I have an abstract factory pattern I was using to instantiate IHttpContextAccessor via Unity (this pattern came over from my .Net Frame work days). Once I moved that code back to the controller and used proper .net core DI to get the dependency via the constructor, everything started working.
There must be something there I'm missing, but I have the code working so I'm happy. If someone could shed light on why one way works vs the other, I'd be happy to hear it.
When you enable application insights by calling .UseApplicationInsights(), it adds HttpContextAccessor. There are many components in ApplicationInsights which require HttpContextAccessor injected to it. eg: ClientIpHeaderTelemetryInitializer.
This is the exact line where this is occuring:
https://github.com/Microsoft/ApplicationInsights-aspnetcore/blob/develop/src/Microsoft.ApplicationInsights.AspNetCore/Extensions/ApplicationInsightsExtensions.cs#L137
We are writing a v8 addon for node.js.
The addon (as you may well know) is a C++ dll.
How do we unit test this?
The simple way is to use node.js scripts to call our exported functions from the addon dll. But this is not a true unit test, as it's across languages.
Has anyone managed to successfully write a C++ unit test for their addon dll?
We have tried, but are getting unexpected errors - we suspect this is because the node-gyp libraries expect everything to be called in the context of node.exe, and because our unit test uses the addon dll "standalone", some things are not getting setup correctly, causing the test to fall over.
If you have managed to use C++ unit tests for v8 addon, please can you detail the best way to do it, and things to look out for?
regards,
Stretch
I was thinking about this, too. But unless you have really lot's of cpp-logic it's perfectly fine to just write cpp-js-combination and unit test the js-implementation as can be observed in the Nan-library, here. Having less logic means here, that the cpp-implementation in the best case is anyhow just the API glue.
When you do have custom logic and write Nan#2-style classes (so, straightforward cpp) you can of course test it the like regular cpp by including it's headers and do some...
void testEquality()
{
CPPUNIT_ASSERT( /* some test*/ );
}
I'm new to Velocity and am using Mocha as my testing framework. I understand how to writ e the tests and structure, but my mirrored app on port 5000 does not seem to have a replicant of my database. I was wondering is there extra configuration I have to do to get that wired up? All my tests fail, but thats because it has no data to compare off of.
Thank you for the help in advance, and if you need more information then I'm more than happy to provide it.
The mirror intentionally has its own database so you can continue development in the main app, but also have your tests run in the background against the mirror.
What you should do before each test (or before all tests) is setup the state you require in the database. For this you can use fixtures. If you put a file called anyName-fixture.js (or coffee) under your /tests directory, Velocity will make this file accessible in the mirror. This file can then setup the data needed for your tests.
Click here for an example of a fixture.
In your test, you can easily call the fixture using a meteor method.
i'm new in web dev and have following questions
I have Web Site project. I have one datacontext class in App_Code folder which contains methods for working with database (dbml schema is also present there) and methods which do not directly interfere with db. I want to test both kind of methods using NUnit.
As Nunit works with classes in .dll or .exe i understood that i will need to either convert my entire project to a Web Application, or move all of the code that I would like to test (ie: the entire contents of App_Code) to a class library project and reference the class library project in the web site project.
If i choose to move methods to separate dll, the question is how do i test those methods there which are working with data base? :
Will i have to create a connection to
db in "setup" method before running
each of such methods? Is this correct that there is no need to run web appl in this case?
Or i need to run such tests during
runtime of web site when the
connection is established? In this case how to setup project and Nunit?
or some another way..
Second if a method is dependent on some setup in my .config file, for instance some network credentials or smtp setup, what is the approach to test such methods?
I will greatly appreciate any help!
The more it's concrete the better it is.
Thanks.
Generally, you should be mocking your database rather than really connecting to it for your unit tests. This means that you provide fake data access class instances that return canned results. Generally you would use a mocking framework such as Moq or Rhino to do this kind of thing for you, but lots of people also just write their own throwaway classes to serve the same purpose. Your tests shouldn't be dependent on the configuration settings of the production website.
There are many reasons for doing this, but mainly it's to separate your tests from your actual database implementation. What you're describing will produce very brittle tests that require a lot of upkeep.
Remember, unit testing is about making sure small pieces of your code work. If you need to test that a complex operation works from the top down (i.e. everything works between the steps of a user clicking something, getting data from a database, and returning it and updating a UI), then this is called integration testing. If you need to do full integration testing, it is usually recommended that you have a duplicate of your production environment - and I mean exact duplicate, same hardware, software, everything - that you run your integration tests against.