I am using grunt version "0.4.1" and grunt-coverjs version "0.1.0". I am writing the task as below:
cover: {
compile: {
files: {
'instrumented/testCoverage.js': ['src/file1.js'],
'instrumented/testDir/*.js': ['src/file2.js', 'src/file3.js']
}
}
}
When i run the above task i am getting error as: Object # has no method 'expandFiles'.
I am not sure what is causing the error.
Also, once the task is done, i think it is generated only the instrumented files, how can i generate the coverage report.
That error means the task isn't compatible with Grunt 0.4.x as grunt.file.expandFiles was deprecated. The author of that module can use grunt.file.expand({filter: 'isFile'}, file.src) instead. Although there is likely more updates that need to be done.
I'm sure the author would appreciate a pull request upgrading the module: https://github.com/jgrund/grunt-coverjs/blob/master/tasks/cover.js#L54
Here is the Grunt migration guide: http://gruntjs.com/upgrading-from-0.3-to-0.4
Related
I'm trying a basic UnitTest with Codeception. No frameworks are used.
My working root is as:
tests |
|-unit
|-Test.php
includes|
|-general
|-Custom.php
In Custom.php
<?php
namespace Custom;
class General {
public static function check(){}
}
My test case is:
<?php
use Custom\General;
use PHPUnit\Framework\TestCase;
final class Test extends TestCase
{
public function testPushAndPop(): void
{
General::check();
}
}
I also have in my composer.json:
"autoload": {
"psr-4":{
"Custom\\":"includes/general"
}
},
When I run
php vendor/bin/codecept run unit
...
1) Test: Push and pop
Test tests/unit/Test.php:testPushAndPop
[Error] Class 'DB\General' not found
#1 /var/www/html/prj/tests/unit/Test.php:9
Codeception Simple Unit Test Not Work To Find My Namespaces
This is less about Codeception but how PHP autoloading works in general and what the configuration of autoloading in Composer is in specific:
{
"autoload": {
"psr-4":{
"Custom\\":"includes/general"
}
}
}
Even the path-segment includes/general does map on the file-system path includes/general/ (composer should have told you to add / at the end of the path-segment), the error message
[Error] Class 'DB\General' not found
#1 /var/www/html/prj/tests/unit/Test.php:9
shows that the namespace of Custom\\ in the Composer configuration is different to the namespace of the class that is not found (which is DB\\).
So even the framework you have in use (you have one and that is the testing framework) may load the composer auto-loader (highly likely), its just that the class is not found.
As #Naktibalda already highlighted in a comment, it is just a plain autoloader configuration issue.
You are right, but why? The IDE does not claim any error... (your reaction)
These are two pair of shoes.
Your IDE most likely does not rely on the autoloader and just guesses the file from the file-system.
Depending how well maintained and configured your IDE is, it perhaps should and could have highlighted you that.
On the other hand, PHP can only rely on the autoloader, in your case you delegate the autoloading to composer(1), not to your IDE.
So maybe improve on that end as well, composer is more central for your projects development than the IDE can be.
So a suggestion:
Whenever changing the composer.json file, I suggest to run composer validate --strict to check your status, then follow with a composer update.
Run this automatically before running your tests. You may not want to run composer update, then run composer install before running the test-runner if you have it as a development dependency.
Example to bind this for a single test run command within your composer.json:
{
"scripts": {
"test": [
"#composer --no-plugins --version",
"#composer validate --strict",
"#composer --no-plugins -q install --no-scripts --no-progress",
"codecept run unit"
]
}
}
you then have a single call to run all the important things in your Composer based project:
$ composer test
...
Running unit-tests is a good way to verify the autoload configuration by the way. With the composer test-script you ensure it is always up-to-date when running the test-suite, too.
You don't need an IDE for this technically, which makes it more portable and stable giving you the peace of mind for your composer based project to grow.
I have an sbt project where docker:publishLocal will create a docker image on my machine for testing, and docker:publish will publish the image to a repository and also publish jar files from the build to a repository.
If my project is a snapshot, I would like to disable publishing to the repositories, while still being able to build the local image.
ThisBuild / publishArtifact := ! isSnapshot.value
does the right thing for the publish command, but it also disables publishLocal.
I want to write something like
if (isSnapshot.value) {
publish := { }
}
but that gives me an error that I do not understand at all:
[info] Loading project definition from /Users/dev/project
/Users/dev/build.sbt:1: error: type mismatch;
found : Unit
required: sbt.internal.DslEntry
if (isSnapshot.value) {
^
Past experience dictates that redefining publish to conditionally call the original version won't work, as
publish := {
if (!isSnapshot.value) publish.value
}
gives warnings that the task is always evaluated.
Is there a way to do this?
The problem with this code is that it evaluates publish.value regardless of the if structure. I recommend reading the documentation on task dependencies. If you want to "delay" the evaluation of a task in one of the if branches, you need to use dynamic task definition:
publish := Def.taskDyn {
if (isSnapshot.value)
Def.task {} // doing nothing
else
Def.task { publish.value } // could be written as just publish
}.value
But apart from fixing your code, you should be aware that there is a special setting for the functionality you want, it's called skip:
publish/skip := isSnapshot.value
Another thing to notice, is the scoping. If you want to override docker:publish, which is the same as Docker/publish in the new syntax, you should add this Docker/ scope prefix to every mention of publish in the code above.
I can successfully use Gradle to compile a fat JAR, but having trouble running the JAR after recently switching from the "compile" dependency specification to the "implementation/api" specification. I have isolated that the problem occurs in only one of the two following cases. The application runs in either case inside IntelliJ.
first/problem:
dependencies {implementation 'no.tornado:tornadofx:1.7.18'}
second/works:
dependencies {compile'no.tornado:tornadofx:1.7.18'}
The JAR compiles in both cases. The problem appears when I attempt to start the first case JAR on the command line and it throws the following error.
C:\aaa_eric\code\testr\mic\build\libs>java -jar mic-1.0-snapshot.jar
Error: Could not find or load main class app.MyApp
Caused by: java.lang.NoClassDefFoundError: tornadofx/App
Here is the JAR task in build.gradle. Is it possible that the tornadofx dependency is available at compile time, but not at run time? Thanks for any help.
jar {
manifest {
attributes 'Main-Class': 'app.MyApp'
}
from { configurations.compile.collect { it.isDirectory() ? it : zipTree(it) } }
}
Changing configurations.compile.collect to configurations.compileClasspath.collect fixed the problem for me.
I was having the same problem and stumbled across this in https://docs.gradle.org/current/javadoc/org/gradle/api/artifacts/ConfigurationContainer.html:
An example showing how to refer to a given configuration by name in
order to get hold of all dependencies (e.g. jars, but only)
apply plugin: 'java' //so that I can use 'implementation', 'compileClasspath' configuration
dependencies {
implementation 'org.slf4j:slf4j-api:1.7.26'
}
//copying all dependencies attached to 'compileClasspath' into a specific folder
task copyAllDependencies(type: Copy) {
//referring to the 'compileClasspath' configuration
from configurations.compileClasspath
into 'allLibs'
}
One thing to note is that configurations.compileClasspath.collect worked for me even when I was using the compile specification instead of implement.
I am trying to run jasmine test using grunt-contrib-jasmine
Below is my Gruntfile.js code
module.exports = function(grunt) {
grunt.initConfig({
jasmine : {
// Your project's source files
src : 'src/**/*.js',
// Your Jasmine spec files
specs : 'specs/**/*spec.js',
// Your spec helper files
helpers : 'specs/helpers/*.js'
}
});
// Register tasks.
grunt.loadNpmTasks('grunt-contrib-jasmine');
// Default task.
grunt.registerTask('default', 'jasmine');
};
Then I tried running "grunt jasmine" command from command prompt. It gives me an error like below
The issue you're describing was reported in this grunt issue. It was then fixed in this commit to grunt-contrib-jasmine on February 13 2016.
As of this writing, the most recent release of grunt-contrib-jasmine is v1.0.0, released on January 26 2016. So, the fix didn't make it into the most recent release, which is what NPM pulls when you do an install.
You can get around this by bypassing the NPM repository and going straight to GitHub for a prerelease version of grunt-contrib-jasmine. You do this by changing your package.json to read:
"dependencies: {
"grunt-contrib-jasmine": "git://github.com/gruntjs/grunt-contrib-jasmine#1e78d891704fa13fe7c7abf4cabf43cefacafcaf"
}
(The commit SHA in the URL just happens to be the most recent one at the time of this writing; feel free to replace it with a later one if you like.)
Ideally, this solution will become obsolete, when grunt-contrib-jasmine releases v1.0.1 (or higher) with the fix commit. Today though, this is what fixed the problem for me.
i created an angular application with yeoman, when i executed grunt command i got the following error
Running "karma:unit" (karma) task
WARN [config]: JASMINE is not supported anymore.
Please use `frameworks = ["jasmine"];` instead.
WARN [config]: JASMINE_ADAPTER is not supported anymore.
Please use `frameworks = ["jasmine"];` instead.
WARN [config]: LOG_INFO is not supported anymore.
Please use `karma.LOG_INFO` instead.
ERROR [config]: Config file must export a function!
module.exports = function(config) {
config.set({
// your config
});
};
how do i solve this error ?
It's just those two predefined terms (JASMINE and JASMINE_ADAPTER)
that should not be used any more. All you have to do is open the
config file ./config/karma.conf.js and comment out those terms and add
frameworks = ["jasmine"];.
Via Yasuhiro Yoshida
apart from #sheplu's answer, there are additional changes that need to be done in karma.conf.js, you can see it in https://gist.github.com/sivakumar-kailasam/6421378
this gist solves your problem of 'Config file must be a export a function!'
The official docs has these changes as well http://karma-runner.github.io/0.10/config/configuration-file.html