PHPUnit works great, I love it actually, problem I'm having is that my hosting plan imposes a 30 second cap on the duration of a query. If PHPUnit tests take longer than that, the connection is closed by the server, and I never get to find out if all my tests passed or not.
Is there an existing automatic way of running an arbitrarily long test suite using AJAX to batch unit tests so that they'd never hit the 30s threshold? As long as each individual test takes less than 30s I think it should work.
Thanks
Why are you running the tests on the production server? Your tests are for running on your development server, to make sure your code is good before sending into production.
You may be able to change the default timeout with set_time_limit (link). That resets the time left to run whenever it's run.
Related
...
$this->browse(function (Browser $browser) {
$browser->visit(url()->route('login'))
->type('email', 'user.one#email.com')
->type('password', 'something')
->press('Login')
->pause(60*60*1000)
->assertRouteIs('dashboard')
...
It works on local which is use APP_URL something like 'https://project.dev' but not work for remote 'https://project.com' and 'http://123.123.12.12'.
Errors or Problems
login test on remote site not work
Different between local and remote
dusk installed in local
dusk not installed in remote
What i did to try solve it
I read that Chrome need HTTPS. I given https to it. Still not work. 😫
I pause the dusk longer. With the dusk browser open, i try type the username & password and submit it. Still not work. 😫
Reported on laravel dusk github as well
Without exact errors, it is difficult, to answer your question,
but from what you described I can provide some hints:
You should never use dusk in production or public site, even if it's configured as dev (security concerns).
I assume, that you are trying to run dusk on your dev, with remote APP_URL. This is wrong concept, cause your tests can manipulate data on db. In case your local and remote uses the same database it might work, but as said, bringing further problems.
Considering above, some of your tests could pass, if you make sure the following requirements are satisfied:
your .env APP_URL matches in both locations
you don't use migrations,factories etc in your dusk tests
you don't write any data to db (via testing register page for example) cause it would be a nightmare to handle these changes, when using the same db and running tests for local and remote
you modify DuskTestCase.php to add --no-sandbox option. This speeds tests up - so you shouldn't need to use pause
Final thoughts.
A good workflow for this would be:
Test your app locally
Commit changes to VCS (Version Control System) with CI (Continuous Integration) - for example gitlab - and run dusk test there.
Deploy to production, if tests are passing, either manually, or via deploy scripts - CD (Continuous Delivery)
We are facing an issue where our tests will start failing or running extremely slow after a certain point. I have seen articles online where others too are facing issues. The primary reason for those failures are memory consumed by browsers while we deal with DOM.
We are using seed project which builds our application using SystemJS. Our Current version of Angular is 2.2.3.
So, I am thinking of a work around where I can either parallel process our test runs (i.e. multiple karma server running, I did try that but it starts to consume 100% CPU) or batch processing. So, batches of small test runs which will ensure that karma is stopped and started again.
Is there a way?
Also, if we are able to achieve that, how to get a consistent coverage? We are using istanbul.
Please let me know if you have any more questions.
e.g. our service and model related tests run in 3 seconds (500+ tests) but our component tests (900+) take 15 mins.
There is pretty good plugin for Karma that allows sharding tests and executing them in parallel - https://www.npmjs.com/package/karma-parallel
We have integrated it in both AngularJS & Angular 4 & 5 projects.
With code-base with more than 2000 tests it is a must.
I'm working on Chef recipes, and often need to test the full run-through with a clean box by destroying a VM and bringing it back up. However, this means I get this message in Vagrant/VirtualBox:
Waiting for VM to boot. This can take a few minutes.
very often. What are some steps I can take to make the boot faster?
I am aware this is an "opinion" question and would welcome some suggestions to make this more acceptable, besides breaking it into a bunch of small questions like "Will switching to an SSD make my VirtualBox boot faster? Will reducing the number of forwarded ports make my VirtualBox boot faster", etc.
I would go for using LXC containers instead of VirtualBox. That gives you much faster feedback cycle.
Here is a nice introduction to the vagrant-lxc provider.
You could set up a VirtualBox VM for Vagrant / Chef development with LXC containers (e.g. like this dev-box). Then take this sample-cookbook and run either the ChefSpec unit tests via rake test or the kitchen-ci integration tests via rake integration. You will see that it's much faster with LXC than it is with VirtualBox (or any other full virtualization hypervisor).
Apart from that:
yes, SSDs help a lot :-)
use vagrant-cachier which speeds up loads of other things via caching
use a recent Vagrant version which uses Ruby 2.0+ (much faster than 1.9.3)
don't always run a full integration test, some things can be caught via unit tests / chefspec already
use SSH connection sharing and persistent connections
etc...
As an another alternative you could also use chef-runner, which explicitly tries to solve the fast feedback problem
I am the only one in my development team having this problems with the unit tests.
Either the debugger, nor a google /stackoverflow or my colleagues could help me.
On my machine the unit tests work 10% of the time. The rest of the time they run until they load a site not found page after a long long time.
I have tried everything:
The entire cache is disabled
I tried it out with two browsers
Restarted Apache and MySQL
Login to the app
Debugging with Firebug
Nothing helps.
I have no clue what the problem is.
I'm running windows 8 over bootcamp for work. So there is not much installed (which could lead into side effects).
If I try it out several times, it will work by chance and pass all tests.
The rest of the time they run until they load a site not found page
after a long long time.
Are you executing the tests in the browser? You should use the console over the web front end. Running the tests in the browser can be problematic.
While building this web service and the app that calls it, we have noticed that the first call to the web service each day is extremely slow. It even will time out on some days. However, every call after that work great. Can anybody shed light on why this might be and how we can get rid of this pain?
Thanks in advance!
If it's an ASP.NET web service, it may be the CLR initializing and loading and verifying the assemblies for the first time. You may want to consider pre-compilation
Agree with the other answers on caching, initialization, etc. As far as a workaround, one possibility may be to set up some sort of daily task (SQL Server job, Windows service, something else?) to simulate a hit to the service each day, so that your users don't experience this first slow request.
If it is an ASP.NET web service, then you might want to check the settings of the application pool the web service is running in, especially the idle timeout which defaults to 20 minutes in IIS7.
Configuring IIS7 idle-timeout
Even if it is not an ASP.NET web service, other web servers will have equivalent configuration settings you have to tweak to keep your web service alive overnight.
Can you duplicate the same behavior on your database? It could just be the db needing to optimise the query for the first run (Maybe the parameter is today's date?).
Are there a lot of static constructors or set up code in the Global.asax class? Because IIS recycles worker processes periodically, the start up code may be running again.
The rule for optimization is: don't guess. Put in profiling to find out exactly what is slow, and then work to make that faster. Everything already posted provides excellent tips on where to start looking for slowness.