I have a project in Symfony4 with doctrine DB, everything flies.
I would like to add some functional and unit testing with Codeception. I followed the docs and added this to my functional.suite.yml:
actor: FunctionalTester
modules:
enabled:
- Symfony:
app_path: 'src'
environment: 'test'
- Doctrine2:
depends: Symfony
# cleanup: true
- \Helper\Functional
# - Db
step_decorators: ~
However, when running vendor/bin/codecept run I get an ugly:
In EnvVarProcessor.php line 131:
Environment variable not found: "DATABASE_URL".
I can't see anything else related in the docs, so not sure what I'm missing.
Does your codeception.yml configuration file have this section:
params:
- .env
- .env.test
- ...
If it has, you need to check the last .env file on the list and make sure that it has the DATABASE_URL variable set.
The other solution is that you remove every file from the list except the .env your app is using. (I don't suggest it)
When each file from this list loads, it overrides the variables that are present in the previous file.
I can't unfortunately explain the mechanisms behind it, but to resolve it I had to add DATABASE_URL environment variable to my OS.
export DATABASE_URL='mysql: ...';
This seemed very weird solution to me (which, again, I have no idea why Codeception would require this), so I kept digging. Something I discovered later, but seems actually cause the whole situation is how I installed Codeception. If you go to codeception docs you can read:
If you don't plan to do acceptance testing, you can get minimal installation of Codeception by requiring codeception/base
EDIT July 2020: Information about minimal install was removed from the linked website, looks like Codeception doesn't provide that option anymore.
This was how I had it installed. After playing around a lot I pulled a version of my code before codeception and installed using composer require codeception/codeception --dev (so the full version). After installing this way I had no issues.
Related
I am trying to troubleshot an error I'm getting in Blazemeter for random-csv-data-set.
The btz.log from the Blazemeter Test run shows the below line...
2021-02-10 10:14:52,518 INFO o.j.r.JARSourceHTTP: Downloading: https://search.maven.org/remotecontent?filepath=com/blazemeter/jmeter-plugins-random-csv-data-set/0.7/jmeter-plugins-random-csv-data-set-0.7.jar
Which could be the point it downloads the jar (latest one?) for the required plugins for my test.
And during the test I am getting an exception from one of the classes in the plugin jar.
I have cloned the plugin project (opensource) and started adding some debug lines and compiled a new jar version.
I was advised If I upload the plugin jar along with my tests files to Blazemeter, the uploaded jar should be taken in for the run. But I still see the exception from the old line numbers which means its still referring to the original jar version 0.7.
How can I override this with my version of the plugin?
I believe you should ask this type of questions via BlazeMeter Support as I doubt that everyone here is fully aware of what's going on there
Whatever.
Looking into Taurus documentation it looks like that Random CSV Data Set Config is being detected and automatically downloaded using JMeter Plugins Manager so in order to prevent Taurus from downloading the "vanilla" version of the plugin which doesn't contain your changes you need to add the following line to your Taurus YAML file:
modules:
jmeter:
detect-plugins: false
I recently got this error when running bin/console doctrine:migrations:migrate:
The metadata storage is not up to date, please run the sync-metadata-storage command to fix this issue.
However, running the sync-metadata-storage command yields the same error.
What can I do?
As mentioned in this GitHub issue one possible fix is to specify the MySQL server version in the server URL:
DATABASE_URL=mysql://root:#127.0.0.1:3306/test?serverVersion=mariadb-10.4.11
Then, you should be able to run the bin/console sync-metadata-storage command.
Read more about this configuration option in the doctrine documentation:
[…] you can pass the serverVersion option with a vendor specific version string that matches the database server version you are using […]
If you are running a MariaDB database, you should prefix the serverVersion with mariadb- (ex: mariadb-10.2.12).
I had to downgrade the doctrine/doctrine-migrations-bundle to version "^2.1"
Not sure if that applies here, but I had issues with doctrine lately aswell.
I did a composer update and ever since then, my project wouldn't run anymore. My issue was based on a new version of the following bundle:
https://symfony.com/doc/master/bundles/DoctrineMigrationsBundle/index.html
They restructred the doctrine_migrations.yaml file and I still had the old one. I tried to change the contents to the new 3.0 version but that lead exactly to your error.
Since the bundle comes with the package: symfony/orm-pack you first have to unpack the to be able to manually change the version inside your composer.json: composer unpack symfony/orm-pack
After unpacking you will see the following line inside your composer.json: "doctrine/doctrine-migrations-bundle": "*", which I changed to "doctrine/doctrine-migrations-bundle": "^2.1". Then i ran composer update again. You may specify only the migrations bundle if thats all you want to update.
Hello so i could fixe my issue just by removing (?versionname=5.7) to the database_url and it worked just fine
I've inherited an old Symfony 2.1 project and having issues getting it up and running - I don't really have the time or budget to go through and upgrade it to something a bit more modern.
When trying to run php app/console I get the following error message:
[Symfony\Component\DependencyInjection\Exception\InvalidArgumentException]
The service definition "kernel.debug" does not exist.
I've been going round in circles trying to find the cause but can't seem to resolve it - any pointers or help would be great.
Try grep -r 'kernel.debug' app/ to locate where it's being used. Make sure that the provided code was working with a supplied vendor/ directory, or you have the result of running composer install nowadays. You can even rename the vendor/ directory (as a kind of quick backup, regardless any other you may have) and run composer install to get rid of other possible inconsistencies.
Turns out it was a large amount of incompatible packages in my composer.json - some of the original packages were looking for alpha and dev builds as the project was cutting edge, 5 years ago. Now pulling alphas and betas broke loads of things. Went through npm to build a set of compatible packages from what I had and it worked.
First of all, I can't use composer because Im under a corporate network. I tried everything to get composer working :
HTTP_PROXY, HTTPS_PROXY, HTTPS_FULLURI ... Nothing is working. Composer diag gives an OK status for http packagist but FAILS for https connectivity. The error it gives me is:
SSL : Handshake timed out.
But that's not my question, I spent to much time trying to get composer working (But if you got a solution, you'll make my day )
My real question is the following : How to install bundles manually
I want to install this bundle : http://knpbundles.com/pierredup/MenuBundle.
What I did to try installing the bundle :
Registering the bundle in appKernel.php :
new \CS\MenuBundle\CSMenuBundle()
Tried to add it in the autoload.php :
$loader->add('CS', __ DIR __.'/../vendor/CS/CSMenuBundle.php');
(Dont know how to add php code properly ... )
But it doesn't work, got the following error :
Attempted to load class "CSMenuBundle" from namespace "CS\MenuBundle".
Did you forget a "use" statement for another namespace?
And then, even if it is not a good practise, I tried to add it to autoload_namespaces.php and did a dump-autoload after that :
'CS\MenuBundle' => array($vendorDir. '/CS/')
I still have an error, but not exactly the same one :
Attempted to load class "CSMenuBundle" from namespace "CS\MenuBundle".
Did you forget a "use" statement for "CS\MenuBundle\CSMenuBundle"?
Now I'm a bit frustrating, I saw many posts (not on Stack) where people scream because we have to use composer to manage dependencies. I totally agree with that, but I can't, so I'm trying to find another way, and as I can't find any clear tutorial which explains how to install vendors without composer, here I am.
Note that I commented on the problems I see with your approach on your question directly.
However, I looked at the package you want to use to see if there would be ANY chance installing it somehow (preferring Composer). I don't think it is possible or feasible.
composer require customscripts/menubundle:dev-master - this would be the easy command for Composer to do everything. However there are problems:
The package you want to use is not registered on packagist.org, so there is no way to simply use Composer on a machine properly connected to the internet, grab the packages, zip them and transfer them to the place you need it.
To work around this, you'd manually add the repository to the composer.json file - this might actually work (however it takes way too much time on my VM). You'll end up with code that was last edited in the year 2012!
The dependencies of that code will likely not work anymore. The composer.json of that package lists "require": {"knplabs/knp-menu-bundle": "dev-master", "symfony/framework-bundle": ">=2.0,<2.3-dev", "jms/di-extra-bundle": "1.1.*"} - even the first "knplabs/knp-menu-bundle" will never work. Remember that the code of this package is from 2012 - now we are in 2016, so "knp-menu-bundle" has seen four years of development on the master branch. There simply is NO WAY of knowing which commit had been used of this package. You'd have to reverse-engineer this lost information.
Additionally, you see why Composer is awesome and doing it manually is bad: In addition to your wished package, you have to download the three additional packages mentioned here.
But detecting packages that have to be added is a recursive task: knp-menu-bundle has a dependency on knp-menu (with no further dependencies) and symfony/framework-bundle (already added). symfony/framework-bundle itself has a dependency on 9 more Symfony packages and doctrine/common... and so on. You have to detect every single package of this and download the correct version manually if you cannot use Composer.
Skipping your original package because that installation wasn't finishing while I was typing my answer, I tried to install knp-menu-bundle to see how many packages would be installed. Composer installed 20 packages, some of them using Symfony in 2.8 (it SHOULD be compatible with Symfony 2.2 stuff, shouldn't it) - and I simply ran composer require knplabs/knp-menu-bundle:1.1.1 to grab a similarly old version of knp-menu-bundle from 2012.
The strength of using Composer is that it supports rapid development by allowing updating quickly, downgrading reliably (if you commit your composer.lock file and always use tagged versions), and simply allowing to add new packages instantly. Not being able to use Composer is a very severe limitation for you as a PHP developer. Talk to your boss or team lead about your company's situation with the HTTPS proxy, and find a solution to use Composer. The alternative is to develop everything from scratch on your own or waste plenty of hours trying to fiddle with manual downloads that don't fit together easily.
Using PHPStorm on a project with Composer and PHPUnit (all of which have already work correctly) how do I run PHPUnit test on a composer plugin inside "vendor" in this case mikey179/vfsStream?
My project structure looks like this:
myscripts/
vendor/
- mikey179
- vfsStream
composer.json
I want to run PHPUnit to test vfsStream plugin.
I was able to run Testing on my own test code (outside vendor directory).
When I run PHPUnit test (That little green play button on top) I got the following:
usr/bin/php /tmp/ide-phpunit.php --bootstrap /path/to/project/vendor/autoload.php --configuration /path/to/project/vendor/mikey179/vfsStream/phpunit.xml.dist /path/to/project/vendor/mikey179/vfsStream
Testing started at 5:53 PM ...
PHPUnit 3.8-g8d770d8 by Sebastian Bergmann.
Configuration read from /path/to/project/vendor/mikey179/vfsStream/phpunit.xml.dist
Time: 2.22 seconds, Memory: 2.25Mb
No tests executed!
PHP Warning: date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone. in /path/to/project/vendor/phpunit/php-code-coverage/PHP/CodeCoverage/Report/HTML.php on line 127
PHP Stack trace:
PHP 1. {main}() /tmp/ide-phpunit.php:0
PHP 2. IDE_Base_PHPUnit_TextUI_Command::main() /tmp/ide-phpunit.php:506
PHP 3. PHPUnit_TextUI_Command->run() /tmp/ide-phpunit.php:268
PHP 4. PHPUnit_TextUI_TestRunner->doRun() /path/to/project/vendor/phpunit/phpunit/PHPUnit/TextUI/Command.php:173
PHP 5. PHP_CodeCoverage_Report_HTML->process() /path/to/project/vendor/phpunit/phpunit/PHPUnit/TextUI/TestRunner.php:465
PHP 6. date() /path/to/project/vendor/phpunit/php-code-coverage/PHP/CodeCoverage/Report/HTML.php:127
Generating code coverage report in HTML format ... done
Process finished with exit code 0
From what I see it's an issue with PhpStorm's helper/wrapper script (/tmp/ide-phpunit.php), which is used for integration purposes (track tests progress in real time -- messages must be formatted in specific way; etc).
Test files do not have standard and expected Test.php ending -- instead they have custom TestCase.php .. and helper script seems to be unable to apply that config option from phpunit.xml.dist file correctly (it will search for *Test.php files only).
If you rename all *TestCase.php file to be *Test.php it will start working in PhpStorm (I've renamed just a few .. and they got detected and executed just fine).
Right now I may only suggest to either rename test files as described above (which is not a good idea in long run if you plan to run those tests on regular basis and keep downloading latest sources of that library) or submit a bug ticket to PhpStorm Issue Tracker explaining the situation: http://youtrack.jetbrains.com/issues/WI and hopefully devs will fix it soon.
You don't run a test on a package in vendor/. You clone the repo and follow the instructions they've given in the testing documentation. In the case of mikey179/vfsStream, there's a github repo: https://github.com/bovigo/vfsStream and it even has a .travis.yml file you can read for inspiration: https://github.com/bovigo/vfsStream/blob/master/.travis.yml
If you're concerned that you've got a version of vfsstream that doesn't pass tests, then you can look at the version that's installed in your project with composer show mikey179/vfsStream and then check out that tag in the repo before running the tests.
The reason is that the package might very well have different dev dependencies than your project, so no matter what else you do you'll end up with broken test runs. Composer ignores dev dependencies for packages other than the main project.