Scenario: I am using Testcafe and Vue and in order to test the app features I need to be logged in otherwise I am pushed to the login page.
I have made use of Roles which helps not to repeat the login process but is there anyway I can login without actually logging?
Is there anyway to test the inside of the app without actually logging in and making a real call? I always need to have a data available in order to enter the app but it doesn't seem ideal.
Is there anyway I can login without actually logging?
If there is, it's a huge security problem you have in the app.
If you want to work around this, the best approach would be to build such a feature on your test environment. But that basically means different code on the test env (or some if-else logic), which is not ideal either and developers won't probably be cheerful about it.
If you want to have this because you have so many tests where you need to log in and it takes time, perhaps think about what you could test on different levels (unit, api), leaving only some end-to-end flows to the UI level. That way you can save a lot of time.
Related
I have a node.js app running in Azure as a webApp. On startup it connects to an external service using a websocket subscription. Specifically I'm using the reconnecting-websockets NPM package to wrap it to handle disconnects.
The problem I am having is that because there are 2 instances of the app running on Azure (horizontal scaling for failover) I end up with two subscriptions at any one time.
Is there an obvious way to solve this problem?
For extra context, this is a problem for 2 reasons:
I pay for each message received and am over quota
When messages are received I process then and do database updates, these are also being duplicated.
You basically want to have an AppService with potentially multiple instances, but you don't want your application to run in parallel. At least you don't want two have two subscriptions. Ideally you don't want to touch your application code.
An easy way to implement this would be to wrap your application into a continuous WebJob, and set its scale property to singleton.
Here is one tutorial on how to set up a nodejs webjob: https://morshemesh.medium.com/continuous-deployment-of-web-jobs-with-node-js-2308f95e63b1
You can then use a settings.job file to control that your webjob only runs on a single instance at any one time. Or you can use the Azure Portal to set the value when you manually deploy the Webjob.
{
"is_singleton": true
}
https://github.com/projectkudu/kudu/wiki/WebJobs-API#set-a-continuous-job-as-singleton
PS: Don't forget to enable Always On. It is also mentioned in the docs. But you probably already need that for your current deployment.
If you don't want your subscription to be duplicated then it stands to reason that you only want one process subscribing to the external websocket connection.
Since you mentioned that messages received will be updated in the db, then it makes sense that this would be an isolated backend process since you made it clear that you have multiple instances running for the frontend server (and whether or not a separate backend).
Of course if you want more redundancy, you could use a load balancer with simple distribution of messages to any number of instances behind. Perhaps some persistent queueing system if you feel that it's needed.
If you want these messages to be propagated to the client (not clear from the question), this will be a bit more annoying. If it's a one-way simple channel, then you could consider using SSE which is a rather simple protocol. If it's bilateral then I would myself probably consider running a STOMP server with intermediary broker (like RabbitMq) and connect directly from the client (i.e. the browser, not the server generating the frontend) to the service.
Not sure if you're well versed with Java, but I made some app that you could use for reference in case interested when we had to prepare some internal demos: https://github.com/kimgysen/zwoop-backend/tree/develop/stomp-api/src/main/java/be/zwoop
For all intents and purposes, I'm not sure if all this is worth the hustle for you, it sounds like you're on a tight budget and that you're looking for simple solutions without too much complexity. Have you considered giving up on load balancing the website (is the load really that high?), I don't have enough background knowledge on your project to judge, I believe. But proper caching optimization and initially scaling vertically may be sufficient at the start (?).
Personally I would start simple and gradually increase complexity when needed.
I'm just throwing ideas at you, hopefully it is helpful in any way to have a few considerations.
Btw, I don't understand why other answers on this question were all deleted (?).
As you know, one of the security measures is preventing everyone from being able to see all site routes and showing them what they need to and they should only see.
I want to fix this problem for SPA web apps, in which all routes are plain in the final build app.js ( even it has been uglified). So I want to know how should I do this? ( i already test some methods but didn't get the right result.)
update
I know that every method using in SPA for this kind of use will eventually include the routes in the spa in the final bundle app.js. as you know in the code obfuscation world, one way is to pack(encrypt) the sensitive data, so nobody can see it in plain text, and show it at runtime when the user actually needs it.
I know it is not a perfect solution, but I believe, it will increase security as a layer.
I just start thinking about communication between two angular (or others framework) applications - what is the best way to do that.
For now, in my application, I used iframe to include the second app and then thanks to postMessage (docs) I can handle actions between apps.
But this solution is getting really hard to maintain because I didn't expect at the begging that I will have to handle soo much type of events.
Let's give you an example:
On Facebook when you go to someone profile you can click "Send message" and it will open a new window on chat application. In other way you can also click on some button in their chat and it will send some action to "main" application.
I just read few articles and start thinking about using WebSockets, using firebase etc but I want to make some more research and ask more expired developers (yes, you! :) ) what they thinking.
So, my question is:
What is the best approach to include two (or more) angular apps?
What is the best approach to handle communication between these apps?
It sounds like you have a really fun problem to solve. There are a number of different ways to go about this, and I'm not sure how your website architecture is setup and what constraint's you have, but I can at least provide some suggestions.
Possible Solutions
Look into separating separate functionality into lazy loaded Angular modules, and treat them as separate websites altogether.
I've done this for a few applications and it gives you some of the flexibility you're looking for. For this to work with your application communication constraints, there are a number of different ways to approach it.
If you can get away with a single application, then you're going to want to look into state management solutions like NgXS, NgRX, Akita, or roll your own statemanagement. I personally roll my own for these things because I rarely need to overhead of the bigger frameworkss, but to each their own.
If you can't get away with a single application, then you're going to want to separate your state into something like FireBase, or a custom websocket app. This would give you better persistence of state, and also allow you to connect completely independent web applications to one another.
Another promising solution to things like this is the tool SingleSpa.
Single spa is a meta web framework that can help navigate and orchestrate multiple SPA's written in different libraries/frameworks into a single application. This would allow you to re-use the existing website that you're using the <iframe> for, but have it bundled within the same parent application. I'm not too familiar with this framework in practice, but I have some coworkers and peers who use it, and it seems promising.
Take a step back and identify the core problem you're trying to solve
This one isn't trying to troll or anything, just helping to take a step back and look over your application from a 10,000 foot overview. Look over how the data is being passed in the solution, are you solving the problem directly? Or is this solution a hack to make due with the constraints that you had at the beginning. Don't be afraid to rebuild parts of the application, or service. Theres a reason people talk about the 10 to 1 rule of writing code.
I understand time and complexity constraints, you have deadlines and other things to deal with. Just make sure you're solving the right problem and thinking about the different edge cases you can leverage to your advantage.
I recognize after writing this out that its not a direct answer per say, but I hope it helped. Message me if you have any questions on this stuff.
I'm developing an Webapp.
It consists of 2 parts. A node rest server and an angularjs client.
The app is structured this way: Rest Server <--> Api Module <--> Angular App
The server is currently well tested.
I have Unit Tests and Integration Tests.
The Integration Tests are accessing a real database and calling the rest api over http.
I think this is as high level as it can get for the server testing.
The integration tests run fast, too.
I'm pretty confident that the way I tested the server is sufficient for my use case and I'm happy with the results.
However I'm struggling how to test the angularjs app.
I have unit tests for the relevant directives and modules. Writing these wasn't an issue.
I would like to write integration tests that cover user scenarios.
Something like a signup scenario: The user visits the website, goes to the signup form, and submits the form with the data.
The angularjs team is moving from ng-scenarios to protractor.
Protractor is using Selenium to run the tests.
Therefore there are two scopes: The app scope and the test scope.
Now I can think of three different abstractions I could use.
And I'm not sure which one suites me best.
Mock the Api Module
Mock the Rest Server
Use the full server
Mock the Api Module
In this case I would need not to setup a server. All Interactions are running in the browser
Advantage:
No server is needed
Disadvantage:
The api is in the browser scope and I have to tamper with this.
I really like this solution, but I find it difficult to mock the Api.
The Api needs to be modified in the browsers scope.
Therefore I need to send the modification from the test to the browser.
This can be done, however I don't see how I could run assertions like mockedApi.method.wasCalledOnce() in the tests scope
Mock the Rest Server
Advantage:
Client would be unchanged
Only one scope to deal with
Disadvantage:
One has to setup the Rest Routes
I could create a complete Mock Rest Server in nodejs.
Protractor Tests are written in nodejs, thus the control of the server can be done in the test.
Before I run the test I can tell the server how to respond.
Something like this: server.onRequest({method: 'GET', url: '/'}).respondWith('hello world')
Then I could do assertions like wasCalledOnce
Use the full Server with Database
Each test is running with a complete server and can add elements to the database.
After each test one can look at the expected elements in the database
Advantage:
Can be pretty sure, that if these tests are running the app is functional in the tested use case
Disadvantage:
I already made a fairly intense integration test with the rest server. This feels like doing the same again.
Setup depends on the full server
Current Conclusion
Mocking the Api would separate the server and the client completely.
Using a Mock Api would be a higher level test, but would require a fake server
Doing a full integration test would give the best reliability, but this is also highly dependant on the server code
What should I pick? What would you do?
I think I answered this same question in the Protractor google group. I am much of the same mind as you about wanting no server but wanting all of my test code in one place (in Protractor) and not split between Protractor and the browser. To enable this, I took matters into my own hand and developed a proxy for the $httpBackend service which runs within Protractor. It allows one to configure the $httpBackend service as if it were running in Protractor. I have been working on it for a while now and its reasonably full featured at this point. It would be great if you could take a look and let me know if I am missing anything important.
https://github.com/kbaltrinic/http-backend-proxy
It is an excellent question, which has nothing to do with a particular tool. I had to face the same problem on a big "greenfield" (ie started from scratch) project.
There is a problem of vocabulary here : the word "mock" is used everywhere, and what you called "integration test" are more "full end-to-end automated functional testing". No offence here, it's just that a clear wording will help to solve the problem.
You actually suggested the correct answer yourself : #2 stub the rest server. #1 is feseable but will be soon too hard to develop and maintain, #3 is an excellent idea but has nothing to do with UI testing and UI validation.
To achieve a high reliability of your front-end, independently of your backend, just stub the rest server, i.e. develop a stupid simple REST server that will idempotent, i. e. will ALWAYS answer the same thing to one http request. Keeping the idempotence principle will make development and test, very, very easier than any other option.
Then for one test, you only check what is displayed on the screen (test the top) and what is send to the server (test the bottom), so that the full UI stack is tested only once.
The full answer to the question should deserve an entire blog article, but I hope you can feel what to do from what I suggest.
Best regards
Here is an approach for writing integration tests for your Angular code. The key concept is to structure your code in a way that lets you invoke the various functions in a way very similar to how it's consumed by the UI. Properly decoupling your code is important to be successful at this though:
More here: http://www.syntaxsuccess.com/viewarticle/angular-integration-tests
This is a great question. This is how I would do it:
As you already have the angular unit tests for the relevant directives and modules this is perfect.
The other thing that is perfect is that your server Integration Tests are accessing a real database and are also making sure the rest api over http works.
So why not just add some high level integration tests that include angular and your server at the same time.
If you can avoid mocking, why not save the work to maintain the extra code, if possible.
Also a good read: http://blog.ericbmerritt.com/2014/03/25/mocking-is-evil.html
Mocking the REST server is the best, cleaner option in my opinion. Try Mountebank (http://www.mbtest.org). An amazing Virtualization Service tool.
I need to run my app always on top of the android system, while the user will be able to exit the app only with his own password. I was told that in order to do that i need to setup and run a Service of my own.
My question is can and how it is done using Phonegap and Jquery. How do i define and run my own service? Thanks for your help.
First, don't do that. I know that doesn't sound like an answer, but trust me, it actually is the answer. What I mean is, no, you don't want your app to be "always on top of the android system." Use the actual Android lifecycle and participate as a good citizen, don't abuse it and try to keep your app always running. I know you may have a use case that makes you think you need to do that, but you most likely don't.
Second, you can write a native service (not JS) and keep it running in the background. This is a a standard Android service. You'll need to create a PhoneGap plugin to hook into your app via the service (or you can create this yourself outside PhoneGap, either way). Then you can either do work in the background, or bring your app to the foreground via the service.
This answer may help: Creating an Android Service with Phonegap? (Have phonegap app run even when closed)
Third, again, don't do that. Most long running services are a bad idea (not all mind you, some use cases require it, a music player, etc, but most do not). It's a much better idea to create an IntentService and schedule an alarm (via AlarmManager) to launch it in the background periodically if you just need to do some occasional background work (fetch data, etc). Regardless of the use case though, a long running background service will consume a lot of resources and make users justifiably wary of your app.
I don't think Phonegap will let you create a service solely in javascript. To be able to make a service, you will have to write at least some native code. See https://stackoverflow.com/a/10427975/1721527.
I've never used Phonegap, but I think you can create a native plugin to talk to the javascript. See http://docs.phonegap.com/en/2.1.0/guide_plugin-development_index.md.html.
See Android documentation on services at http://developer.android.com/guide/components/services.html.