I have a question about generating code coverage in Go(lang) projects.I have this simple structure:
ROOT/
config/
handlers/
lib/
models/
router/
main.go
config contains configuration in JSON and one simple config.go that reads and parses JSON file and fills the Config struct which is used then when initializing DB connection. handlers contains controllers (i.e. handlers of respective METHOD+URL described in router/routes.go). lib contains some DB, request responder and logger logic. models contains structs and their funcs to be mapped from-to JSON and DB. Finally router contains the router and routes definition.
Basically just by testing one single handler I ensure that my config, logger, db, responder, router and corresponding model are invoked (and tested somehow as well).
Now if this would be a PHP or Java or I don't know what else language, having and running that single handler test would create a code coverage also for all other invoked parts of code even if they are in different folders (i.e. packages here). Unfortunately, this is not the case in Go.
And there is very little code in most of my lib files having just one method (like InitDB() or ReadConfig() or NewRouter() or Logger()) so to be able to have code coverage for them I have to create stupid tests in these packages as well while they were already invoked and tested by testing the main URLs handling packages.
Is there any way how to get code coverage from packages also for included other packages within one project?
You can import your packages within a single test and write tests for them based on how they'll be used within your application. For example, you can have one test, main_test.go which imports all the other packages, and then you write tests for the methods in the imported packages.
Like this (in main_test.go):
package main
import (
"testing"
"lib"
"models"
"handlers"
// etc
)
// testing code here
However, in my personal opinion, it might be better to make sure that each package does what it should and that only. The best way to do that, is by testing the individual package itself, with its own test suite.
Related
I'd like to split my integration tests into multiple files (because it's getting long). This can be easily done:
/tests/
/data/ // <- dataset for testing
a_tests.rs // <- this contains "common" functions which I'd like to use in b_tests.rs
b_tests.rs
However, a_tests.rs contains some functions which I'd like to use in b_tests.rs. For example a common Lazy once_cell which reads the data file only once. And also a fn common_func(_) which does assertion based on numerical comparisons of the results.
So how do I import objects from a_tests.rs in b_tests.rs?
Per the Rust documentation on integration tests each file in the tests directory is compiled into a separate crate, but:
Files in subdirectories of the tests directory don’t get compiled as separate crates or have sections in the test output.
So you can have this file structure:
/tests/
/common/
mod.rs
/data/
a_tests.rs
b_tests.rs
Then move your shared functions from a_tests.rs into common/mod.rs and you can import them into a_tests.rs and b_tests.rs via mod common;
My Dart package is currently laid out in the following manner:
lib/
mypackage.dart
src/
mypackage_util.dart
test/
mypackage_test.dart
Inside mypackage.dart, I'm using the part, part of import strategy to use
mypackage_util.dart in mypackage.dart, as recommended by the Pub Layout
conventions.
On the test side, I took inspiration from Seth Ladd's example of using
unittest,
which shows him creating a new library for his tests, which makes sense to me.
Unfortunately, this leads to the inability to import mypackage_util.dart into
mypackage_test.dart, which means I can't test classes or functions from
mypackage_util.dart, or anything in src/.
The solutions I'm imagining are;
Make mypackage_test.dart a part of the main library, but this seems to make
it impossible to just run the test code stand-alone.
Take mypackage_util.dart out of src/, but this seems to imply that you
can never unit test src/ code in packages, which seems silly and exposes
code I don't want to.
Should I take one of the above approaches, or am I missing something?
Update:
The above situation was due to a library import conflict (see Chapter 2. Dart Tour's Libraries and Visibility section for solutions to library conflicts). See comments below.
If lib/mypackage.dart declares the library and includes lib/src/mypackage_util.dart using part/part of you just need to include lib/mypackage.dart in your test - or is your problem that you want to test private classes/functions contained in lib/src/mypackage_util.dart?
My services.js file was getting quite large so I decided it'd be best to split out the individual services into separate files (service1.js, service2.js, etc).
Unfortunately, this broke all my unit tests. I'm no longer able to import the service dependencies into my tests. I'm seeing errors like this when I run my unit tests:
Error: [$injector:unpr] Unknown provider: Service1Provider <- Service1
I can't find any article on the web that addresses these issues. My app structure is pretty standard and OOTB, nothing really different from angular-seed (except of course the separate files for each service).
Please let me know if you need more info.
I currently work with #mtical, and it turns out the error was indeed in karma.conf.js. As he said, we broke apart our services into multiple files, and our main service file was named "service.js". By default, karma loads all js files that are not explicitly listed in the karma.conf.js file in recursive alphabetical order.
This was causing our "service.js" file to be loaded after all of our other service files, which were listed before that file when in alphabetical order. Unfortunately, all of those other services had "service.js" as a dependency, so when our tests ran, they weren't able to find the services we needed.
The solution was to explicitly list "service.js" before the recursive loading of other files in our karma.conf.js file, as follows:
...
files : [
'app/lib/angular/angular.js',
'app/lib/angular/angular-*.js',
'test/lib/angular/angular-mocks.js',
'app/js/services/services.js',
'app/js/**/*.js',
'test/unit/**/*.js'
],
...
I need to write unit tests for an existing Java REST server.
The GET methods are very similar and I am thinking that I can write a small unit test generator that will use reflection to introspect the GET methods and the POJOs they consume to generate (boilerplate) unit tests.
Each test will be generated with a small syntax error so that they cannot be run as is, but must be examined by a developer and the syntax error corrected. I am hoping that this will as least assure that the tests are sane and look reasonable.
The generator will be run from the command line, passing in the class-under-test, the output directory for the unit tests, etc.
I don't want the class files for the generator to be added to the WAR file, but the generator needs to have access to the class files for the REST server.
My project directory is a "standard" Maven hierarchy: project/src/main/java, project/target, etc.
Where is the best place to put the generator source code? Under project/src/main/java? Under project/src/generator/java? Somewhere else?
I know how to exclude the generated class files from the WAR file if they all are included under a specific package (e.g. com.example.unit_test_generator).
This scenario sound like a maven-plugin to me. Furthermore the usual place for generated code is under target/generated... which means target folder ...take a look at maven-antlr3-plugin or maven-jaxb-plugin to see where they usually put generated code into. Never put generated code into src/ structure...But may be you have to change the location and to put into project/src/main/ ...But if these classes are some kind of tests the have to be located under project/src/test instead.
I have a rails app, plus code in lib. I have the spec directory under RAILS_ROOT.
How should I put my tests in spec?
Currently, I am thinking of the following:
spec/lib
spec/controllers
spec/models
Further, I do some common setup / use common steps (e.g., generate an invalid user) in many tests. Where do you recommend I put the modules that do the common setup /steps in my rspec tests?
Your proposed directory structure is fine.
As for your helper modules, a common idiom is for these to go in the spec/support directory. You can include them all automatically by placing the following code into your spec_helper.rb file:
Dir[File.expand_path('../support/**/*.rb', __FILE__)].each { |f| require f }
You could just place the code directly in spec_helper.rb itself, but that can get messy and they could be wiped out by regenerating the helper file.