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.
Related
I have an AWS lambda API that uses a lambda layer with some helper functions.
Now, when deployed AWS forces a path for the layer that's something like /opt/nodejs/lib/helpers/awsGatewayResponses. However, locally I have another folder structure which (on my local machine) would make the path is layers/api-layer/nodejs/lib/helpers/awsGatewayResponses. (Cause I don't want to have a folder setup that /opt/nodejs/lib/...)
However, I'm setting up some tests using Jest and I've come across the issue that I have to change the imports which is of the format /opt/nodejs/lib/helpers/... to be layers/api-layer/nodejs/lib/helpers/ otherwise I will get import errors - and I don't want to make this change since it is not aligned with the actual deployed environment.
I'm looking for something that can change my paths to be layers/api-layer/nodejs/lib/helpers/ only when I'm running tests. Any ideas on how I can make some kind of dynamic import? I want to run some tests automatically on Github on commits.
Thanks in advance! Please let me know if I have to elaborate.
I have two differents apps using a gruntfile.js and a package.json and when i launch locally my second app (providing only 1 functionnality, thats why i trying to merge it with the other), this works, but when i try to works the functionnality by merging the second app in the principal app, it says that modules are missing.
My principal app is the BPMN editor from: https://github.com/bpmn-io/bpmn-js
And the second app is the BPMN-diffing from: https://github.com/bpmn-io/bpmn-js-diffing
My BPMN_editor's Gruntfile is minifying BPMN_editor's .js files, then i tried to do the same for BPMN diffing's js files. but nothing is working, my node server wont run normally (while hes working without this BPMN diffing).
I dont understand how to use the bpmn diffing, should i make an npm install to install all dependencies of bpmn diffing, and then make an npm install of the bpmn editor to install dependencies ? or should i merge the Gruntfiles and the package.json files ?
Thanks a lot
Fantemis
If they are based upon two differrent configurations, I would prefer using a load balancer or a reverse proxy to load them on the server. Merging the projects takes a little more insights from you and a little effort. The effort always depends on the setup. I would give you a little tip, but I am not seeing a Gruntfile in your main principle repository.
A little insight into "Reverse Proxy vs. Load Balancer"
What is the difference between Reverse Proxy and Load Balancers
Alternative 1 (preferred):
You could however create a small node.js server, which is handling the serving of those two applications, like the following:
- bpmn_root
|- principal
|- diffing
Afterwards you just need to write a little script, that is building both things on the server you want it to be deployed, and then you just need to do node SCRIPT_NAME.js.
Further reading, and another post about this.
Alternative 2:
You can use Docker. I am not very aware of how to use Docker to power such thing, but it is "as simple as" creating an Nginx configuration, which is doing the reverse proxy stuff for you.
Alternative 3:
Using the load balancer, which is handling the reverse proxy automatically. This is also a little more complex and needs some more learning to do. You can find plenty of tutorials on this however on the internet.
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.
This is probably a really dumb question, but I'm not sure. If I have a node.js application and a much of tests built with Mocha, I can run them on my server no problems, using mocha. However, is there any way to invoke the unit tests through a browser and just pipe the results to the page? For development, I'd like to have a page on my website that shows the results of the tests.
Every time I search for how to do this, it's testing the actual browser code I'm finding (the dom, the UI etc), but it's actually just that I want to see the results of the tests run server-side but from the browser!
Thanks in advance!
Sure, create a route in Express that executes mocha and returns the result to the browser. Take a look at child_process.fork to execute mocha: http://nodejs.org/api/child_process.html#child_process_child_process_fork_modulepath_args_options
And don't forget to turn it off before going into production!
Separately, I would highly recommend to you the concept of continuous deployment, and specifically the service CircleCI, which for $19 automatically runs all of your tests every time you push to Github.
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.