anyone what is the command to enable the logging (that shows all the requests, even javascript errors) when running Capybara?
I used to use that one-line to enable for troubleshooting..
In your spec_helper.rb, add this
Capybara.default_driver = :webkit_debug
and run your specs.
Related
In any ingress controller like https://traefik.io/ there is usually a DEBUG mode to run. In this mode you can actually see the headers in the request which help in debugging.
However in https://docs.konghq.com/kubernetes-ingress-controller I am unable to find the same.
I have installed kong using helm and it installs and runs fine.
I want to be able to see the headers in a request and I can't seem to find a way around it. There is no logging level defined in values.yaml file.
Turns out you can enable debug mode by using the following environment variable. Add the following with other environment variables to get log in DEBUG mode
env:
log_level: debug
However, to see the values of requst headers and response you will need the following
plugin
You might want to redirect it to /dev/stdout so it comes in output of kong logs.
for debugging one can send a header; Kong-Debug: 1 (see https://docs.konghq.com/gateway-oss/2.5.x/proxy/#evaluation-order ) and there is an upcoming change in 2.6 that might be helpful as well; see https://github.com/Kong/kong/pull/6744
I use log from import 'dart:developer'; but it seems that it does not print anything when I use from unit test.
What should I use for logging in both test and dev environments but not in production?
Thanks.
dart:developer only works in debug environments where the Dart vm service is available. As such, launching the unit tests with the debugger attached should work fine. It programmatically interacts with the Dart VM and debugger, so if those aren't attached it won't work properly.
However, logging can be very helpful for production environments as well, so I’d recommend migrating to a different package for a robust logging service across environments. dart:developer is not designed as a logger.
Messages sent through dart:developer log() will be handled via the Dart VM's native code implementation, note the external function definition in the src code. Tools such as the Flutter Devtools are then free to subscribe to receiving and displaying these messages.
In Flutter apps, the logging will be sent to usual app console output, however if you are using this for a Dart command line application or want output when running unit tests for Flutter apps, you should be able to see that via IDE's, in theory both the VSCode and IntelliJ Dart/Flutter plugins have explicit support added to them to display the output for log(), though currently in the case of DartCode there maybe a bug preventing that.
In theory you can also add support using the Dart vm_service package to read the log messages and send the to stdout/stderr yourself when running unit tests, but in this case it may just be easier to switch to using the logging package published by the Dart team and then you'll likely want to enable explicitly send the output to stdout and/or stderr in the Logger's listen() callback:
// pass true to enable output to stderr
Logger.root.onRecord.listen((LogRecord rec) {
final mesg = '${rec.level.name}: ${rec.time}: ${rec.message}';
if (true == useStd) {
if (rec.level >= Level.SEVERE) {
stderr.writeln('$mesg\n${rec.error}\n${rec.stackTrace}');
} else {
stdout.writeln(mesg);
}
} else {
developer.log(mesg, level: rec.level.value, error: rec.error);
}
});
See the implementation in my package for more details.
Is it possible to integrate a headless browser with locust? I need my load tests to process client side script that triggers additional requests on each page load.
That's an old question, but I came across it now, and found a solution in "realbrowserlocusts" (https://github.com/nickboucart/realbrowserlocusts) - it adds "Real Browser support for Locust.io load testing" using selenium.
If you use one of its classes (FirefoxLocust, ChromeLocust, PhantomJSLocust) instead of HttpLocust for your locust user class
class WebsiteUser(HeadlessChromeLocust):
then in your TaskSet self.client becomes an instance of selenium WebDriver.
One drawback for me was that webdriver (unlike built-in client in HttpLocust) doesn't know about "host", which forces to use absolute URLs in TaskSet instead of relative ones, and it's really convenient to use relative URLs when working with different environments (local, dev, staging, prod, etc.).
But there is an easy fix for this: to inherit from one of realbrowserlocusts' locusts and pass "host" to WebDriver instance:
from locust import TaskSet, task, between
from realbrowserlocusts import HeadlessChromeLocust
class UserBehaviour(TaskSet):
#task(1)
def some_action(self):
# self.client is selenium WebDriver instance
self.client.get(self.client.base_host + "/relative/url")
# and then for inst. using selenium methods:
self.client.find_element_by_name("form-name").send_keys("your text")
# etc.
class ChromeLocustWithHost(HeadlessChromeLocust):
def __init__(self):
super(ChromeLocustWithHost, self).__init__()
self.client.base_host = self.host
class WebsiteUser(ChromeLocustWithHost):
screen_width = 1200
screen_height = 1200
task_set = UserBehaviour
wait_time = between(5, 9)
============
UPDATE from September 5, 2020:
I posted this solution in March 2020, when locust was on major version 0. Since then, in May 2020, they released version 1.0.0 in which some backward incompatible changes were made (one of which - renaming StopLocust to StopUser). realbrowserlocusts was not updated for a while, and is not updated yet to work with locust >=1.
There is a workaround though. When locust v1.0.0 was release, previous versions were released under a new name - locustio with the last version 0.14.6, so if you install "locustio==0.14.6" (or "locustio<1"), then a solution with realbrowserlocusts still works (I checked just now). (see https://github.com/nickboucart/realbrowserlocusts/issues/13).
You have to limit a version of locustio, as it refuses to install without it:
pip install locustio
...
ERROR: Command errored out with exit status 1:
...
**** Locust package has moved from 'locustio' to 'locust'.
Please update your reference
(or pin your version to 0.14.6 if you dont want to update to 1.0)
In theory you could make a headless browser a Locust slave/worker. But the problem is that the browser is much more expensive in terms of CPU and memory which would make it difficult to scale.
That is why Locust uses small greenlets to simulate users since they much cheaper to construct and run.
I would recommend you to break down your page's requests and encode them as requests inside of Locust. The Network tab in Chrome's Dev Tools is probably a good start. I've also heard of people capturing these by going through a proxy that logs all requests for you.
You could use something like browserless to take care of the hosting of Chrome (https://browserless.io). Depending on how you brutal your load tests are there’s varying degrees of concurrency. Full disclaimer: I’m the maker of the browserless service
I think locust is not desinged for that purposes, it is for creating concurrent user to make http requests so I didnt see any integration with locust and browser. However you can simulate browser by sending extra information in the header with that way client side scripts will also work.
r = self.client.get("/orders", headers = {"Cookie": self.get_user_cookie(user[0]), 'User-Agent': self.user_agent})
The locust way of solving this is to add more requests to your test that mimic the requests that the javascript code will make.
I structure my locust tests to parse the JSON response from an early request in the app's workflow. I then randomly pick some interesting piece of data from that JSON, and then issue more requests that mimic what would happen in the browser if the user had clicked on that piece of data.
How can I get a REST client (such as the one built into PHPStorm or POSTman) to work with XDebug?
In my current set-up of XDebug, using PHPStorm and the Bookmarklet provided I'm able to get it working in both Chrome and Firefox - but as soon as I try with POSTman or any other REST client, I can't figure out how to get it started.
Cheers.
You can use one of these approaches:
Configure your Xdebug (by editing php.ini) to attempt to debug every PHP script. The key option:
Xdebug v2: xdebug.remote_autostart = 1
Xdebug v3: xdebug.start_with_request = yes
Add Xdebug session start parameter to the actual URL (XDEBUG_SESSION_START={{KEY}} -- https://xdebug.org/docs/step_debug#manual-init), for example: ?XDEBUG_SESSION_START=PHPSTORM
Pass Xdebug cookie as part of the request (the one which is set by bookmarklet or browser extension, for example).
For this to work: make sure that "phone handle" icon is activated in advance in PhpStorm (Run | Start Listen for PHP Debug Connection).
P.S. If you are using Postman, Insominia or alike (another REST client) then the best / most transparent way IMO is to use Xdebug cookie. You're most likely already using separate Environments (e.g. "dev", "test", "production") so you can have such a cookie only where it is needed (depends on the tool and version used of course).
This way there is no need to edit the URL (even if you have it as a "conditional parameter" that is present for some environment and absent for another) or configure Xdebug to "debug all requests" at all.
An example of such Xdebug cookie from my Postman (edit it as needed; here it is set for the local some-domain.local.test fake domain):
XDEBUG_SESSION=value; Path=/; Domain=.some-domain.local.test; Expires=Tue, 19 Jan 2038 03:14:07 GMT;
Since the host URL should be a part of your Environment (e.g. the endpoint URL will be like {{host}}/api/v1/welcome) then such cookie will be sent to the dev domain only and not to the production one.
Just add ?XDEBUG_SESSION_START=filter_string at the end of the url, for eg:
https://new-supplier.local/api/login?XDEBUG_SESSION_START=PHPSTORM
PHPSTORM is my default filter string, you can use whatever you want. Your editor should be set up to filter connections by IDE key (filter string), and thats it. You should be able to debug the same way as from Chrome or FF.
Warning!
xdebug >= 3.0 has changed the parameters in php.ini.
After upgrading xdebug, most of the answers here will not be relevant.
Refer to:
https://xdebug.org/docs/upgrade_guide
Basically, you need to add something like this to your php.ini:
xdebug.mode=develop,gcstats,coverage,profile,debug
xdebug.start_with_request=1
xdebug.idekey=PHPSTORM
This was driving me crazy. I just updated to PHP 7.1 and xdebug that was working no longer worked. I updated the xdebug.so file (Linux) and php --version indicated that xdebug was indeed being loaded and working. But when I would use Postman the debugger never kicked on.
Here's the solution. If you are using Apache as your server then you need to enable the PHP 7.1 mods and reboot Apache: sudo service apache2 restart
xdebug.remote_timeout = 60000
Worked for me. As my Mac was very slow, and Remote debugger was timed out after 200 ms (Default value)
What finally got my Postman/PHPStorm Xdebug working was adding a PHP Remote Debug configuration in PHPStorm:
Run -> Edit Configurations -> + -> PHP Remote Debug
I just set the name to localhost and saved it - no IDE Key, etc.
you can set xdebug cookie into postman to use it from postman as well.
their are one link Cookies under the Send button click on it. and add new cookie. XDEBUG_SESSION = PHPSTORM their and save
Configure PHPStorm XDebug to trigger on RESTful API requests
Please, check this answer => https://stackoverflow.com/a/73802240/13321079
According to the Ruby on Rails Guide: Caching, caching is disabled by default in the development and testing environments. If I make a small CSS change, run rails server and access my site at localhost:3000, I can see my change. However, if I access my rails server on my iPhone at 10.0.1.2:3000, the CSS doesn't update, even Chrome in Incognito Mode. When I try different iPhone that has an empty cache, the change is there.
I found a stack overflow post that described the same problem. Here were the suggested solutions:
Remove the public/assets directory. I don't have one.
Add config.serve_static_assets = false to environments/development.rb. It's already there.
Delete /tmp/cache/assets, add config.serve_static_assets = false to environments/development.rb and restart the server. I tried this and it didn't work.
Here's my relevant environments/development.rb config:
# In the development environment your application's code is reloaded on
# every request. This slows down response time but is perfect for development
# since you don't have to restart the web server when you make code changes.
config.cache_classes = false
# Show full error reports and disable caching
config.consider_all_requests_local = true
config.action_controller.perform_caching = false
I'm pretty sure this is happening because Rails only does fingerprinting in production: http://guides.rubyonrails.org/asset_pipeline.html#in-production
This means that in development browsers that are more cache-aggressive can run into this issue.
Try adding this to your development.rb:
config.assets.digest = true
Or more preferable something conditional for when you're doing mobile development
# One of the few exceptions I'd make to a no ENV variables rule
# for my rails environment config files
config.assets.digest = true if ENV["MOBILE_DEBUG"]
How are use accessing your local machine via your iphone ?
have you configured any network settings or you push it to a different server and access from there, because the thing is if you are pusing it to a different server , that sever might be running in the production mode.
HTH
I don't have an iPhone to test, but it sounds like a normal browser caching issue. Try these instructions for clearing the browser cache. If that works, you'll need to do it each time you update your CSS (or J
I had a similar problem. It happened because my config/environments/development.rb had contained config.asset_host = 'http://localhost:3000'
I've removed it and all works fine.