I'm trying Vuejs unit test using karma+mocha+chai+webpack and get code coverage with istanbul.
Here's the issue, when I import some utils function or some other component in my component to be tested, the code coverage I got will include those utils code.This is not what I want.
In the component I want to test :
// src/home/mod_setting/upgrade_management/common/uploader.vue
import FileUploader from 'src/components/file_upload/index';
import Uploader from './uploader';
import logger from 'src/util/logger';
The coverage report will include these files.
Is there a solution ?
This should be possible by affecting the 'preprocessor' entry in your karma conf : only files matching this will be monitored for coverage.
See following issue > https://github.com/karma-runner/karma-coverage/issues/13
In your case something like
preprocessor: { 'src/!(util)/**/*.js' : 'coverage' }
should do the trick
Related
I have a project that is using webpack to bundle all code into a single file. The project is using Typescript and it is working fine at the moment.
I've gone to add unit testing and jasmine seems to be the way (one of the many ways) forward. Its actually jasmine-core that is included in the package.json - not sure how much of a difference that makes.
So running a very simple test such as
it('true is true', function(){ expect(true).toEqual(true); });
works fine.
But when I add tests that require the use of an import - eg
import MyService = require('./MyServices');
then when I run the tests it complains as it doesn't know what 'require' is.
Uncaught ReferenceError: require is not defined
Now I'm guessing this is because I need to package up the test module in a similar way that I package up the main project.
So what is the best way to do this?
Should I have multiple entry points in the webpack.config.js file - one for each *.spec.ts file?
Or is there a way to have say accept an unknown number of spec files
entry:[ *.spec.ts ] and have it output a js file for each one - *.spec.js
You can use karma/karma-webpack to run all the tests using webpack for resolving the imports. You can take a look at this repository for a simple configuration.
You can also specify an index.spec.ts as en entry point and make this file require all the spec files if you don't want to make one entry point for each spec.ts in your webpack's configuration file.
I'm working on creating an ember addon, and I'm a bit stuck trying to write tests for it. This addon implements a command line option, rather than shipping components etc. As a result, none of the moduleFor type test helpers are relevant for me in the out of the box qunit tests. I'm not rendering any components, I just want a test runner to exersize the implementation behind my command line option.
To write my tests, I'll need to just require my various source files that are up in my addon. For example, files sitting in root/lib. I can't get a require/import that can find these files in a qunit integration test under root/tests/integration. Is this possible? I need a relative path like:
import foo from '../../../lib/foo'
But nothing up there seems to work. The folder structure created for an addon is like:
root
app
lib (was planning on putting my addon impl here)
tests
dummy
helpers
integration
example-test.js (trying to reference code out of the lib folder from here)
It seems like my options in this case are just to fall back to some plain old JS unit testing (qunit, jasmine etc), based up in the root of the addon, not using any ember magic or the dummy app. I would like to stay on the 'out of the box' path provided by ember generate addon, but it seems like I need to go my own way here, so I can reference my source files.
Use
import foo from 'myApp/lib/foo'
I am trying to write a unittest for my class. First of all, i install the package unittest and create a spec folder to save all my unittest files. Then i create a test dart file with following contents:
library i18n_test;
import 'package:unittest/unittest.dart';
void main() {
}
When i run the file, i got the following error
Unable to open file: D:\Dart\i18n\bin\spec\packages\unittest\unittest.dart'file:///D:/Dart/i18n/bin/spec/i18n_test.dart': error: line 3 pos 1: library handler failed
import 'package:unittest/unittest.dart';
As i mentioned, i saved my unittest file in the spec folder, i think that because the compiler could not find the package unittest.
My Folder structure looks like:
What do i wrong?
The error is caused by a missing packages symlink in your spec folder.
see https://code.google.com/p/dart/issues/detail?id=16947
Anyway
unit tests should be put into the test folder (i18n/test).
This way your test code won't be included in the build output.
It's best to have most of your code in the lib folder to make it easy to import into your tests using package imports like:
import 'package:i18n/my_dart_file.dart';
you should still be able to import from bin or web using relative imports like
import '../bin/my_dart_file.dart';
but that form is not very refactoring-friendly.
I have a large grails project split into several 'in place' plugins to keep things nice and modular. One of my plugins, called 'core services', contains all my domain classes, and also some nice set up work in an abstract test class (adding mock domain instances, etc) that is shared by a number of unit tests.
This is all great for unit tests that also live in the plugin, but I'd like to use that abstract test class to set up mock data in other grails projects' tests that uses that plugin. It doesn't seem that plugins' test classes are included on the classpath when running tests. Is there a way I can tell Grails to include them?:
//this abstract test class is in the core service plugin's test directory. My IDE has no problem with this import
import com.myproject.coreservices.service.AbstractGiftInstanceRelatedUnitTest
//this test class is in the project that uses the plugin
class ClaimGiftControllerTests extends AbstractGiftInstanceRelatedUnitTest {
.. my tests
}
And the output (non important parts removed):
| Error Compilation error compiling [unit] tests: startup failed:
...../test/unit/com/myproject/ClaimGiftControllerTests.groovy: 3: unable to resolve class com.myproject.coreservices.service.AbstractGiftInstanceRelatedUnitTest
# line 3, column 1.
import com.myproject.coreservices.service.AbstractGiftInstanceRelatedUnitTest
^
You can put your AbstractGiftInstanceRelatedUnitTest into the src/groovy folder of your plugin, instead of the test folder. That way you can include it in the test cases of the plugin and your other projects.
I'm having trouble creating a test suite in Django 1.3.
Say I have an installed app in a directory called app_name. One of the files in that directory is foo.py which defines a class named Foo. I want to test that, so I also have a file that directory called foo_test.py which defines a class named FooTest. That file looks like:
import unittest
import foo
class FooTest(unittest.TestCase):
def setUp(self):
self.foo_instance = foo.Foo()
... etc
Now down the line I'll have other test cases in other files, and I'll want to run them all as part of a test suite. So in the same directory app_name I created a file tests.py which will define the suite. At first I defined it like:
import foo_test
from django.test.simple import DjangoTestSuiteRunner
def suite():
runner = DjangoTestSuiteRunner()
return runner.build_suite(['app_name'])
Unfortunately, this fails because calling runner.build_suite(['app_name']) searches app_name for a tests.py file, executes suite(), and this continues recursively until the Python interpreter stops everything for exceeding the maximum recursion depth.
Changing runner.build_suite(['app_name']) to
runner.build_suite(['app_name.foo_test'])
or
runner.build_suite(['app_name.foo_test.FooTest'])
leads to errors like ValueError: Test label 'app_name.foo_test' does not refer to a test.
And changing it to:
runner.build_suite(['foo_test'])
or
runner.build_suite(['foo_test.FooTest'])
leads to errors like App with label foo_test could not be found.
I'm kind of out of ideas at this point. Any help would be very much appreciated. Thanks!
See the Python documentation for organizing tests, and use one of the alternative methods there to build your test suite. Incidentally, none of the recommended methods employ build_suite.