I have thrift generated code in my project? How do I stop this from affecting my coverage stats? They're dismal.
This help message from go test seems to suggest you can filter the packages you're testing:
-coverpkg pkg1,pkg2,pkg3
Apply coverage analysis in each test to the given list of packages.
The default is for each test to analyze only the package being tested.
Packages are specified as import paths.
Sets -cover.
Another simpler option, and this is what I do, is to import the generated code as a library package that sits outside your code tree, and thus the cover tool ignores it in its stats.
e.g. if your app is github.com/Fuser97381/myproj, put the generated code in github.com/Fuser97381/protocols. Then your code looks like this:
package main
import (
"github.com/Fuser97381/protocols/myproto"
"git.apache.org/thrift.git/lib/go/thrift"
)
...
Related
I want to use imported functions in TestCafe Scripts (which are basically copied into the test method). To me these scripts would be great to create reusable code snippets.
But I did not find a place where I could import a module which is then added to the import statements in the header of the test file.
An example:
I have a test-function I use for visual regression tests. It basically takes a screenshot of the page and compares it to a screenshot stored on disk. Since this also includes reading and writing files from/to disk using nodes fs API and calling packages like graphicsmagik, it quickly becomes a huge script. I might be able to copy it into a a TestCafe Script block, but it is not reusable and hardly scales.
Is there something I missed?
Of course I could create some command-line task that adds the import line to the top of all generated js files. But the test would only work after someone made them js files and ran my script. It would not be possible to run these tests directly from TestCafe Studio.
You can put your code to a separate module and import it using the Run TestCafe Script:
I have a simple program written in Golang. It's an API. So inside the project folder, there's a folder named cmd containing my main package (used to initialise the app and defines the endpoints for the API). There's also a folder named after my program, containing multiple files from a package also named after my program. This package serves as the model to do all the necessary queries and contains all the types I have defined.
I also created a folder called test. It contains all my test files under the package named test. The problem is that to run the tests, I have to access my main package ! Is there a way to do that in Golang ? I tried simply using import "cmd/main" but of course it doesn't work.
I also had an idea. Perhaps I could move all my initialising functions (in the cmd folder) to the package named after my program. This way I could do a regular import in test. And I create, inside of cmd, a main.go in the main package that serves as the entry point for the compiler.
I'm new to Go so I'm not really confident. Do you think it's the right way ?
Thanks.
EDIT : Apparently some people think this question is a duplicate, but it's not. Here's the explanation I gave in on of the comments :
I read this post before posting, but it didn't answer my question
because in that post the person has his tests in the main package. The
reason why I asked my question is because I don't want to have my
tests in the main package. I'd rather have them all in a test folder
inside the same package.
What you want to do is not not possible in GO (assuming you want to test private functions).
because I don't want to have my tests in the main package. I'd rather
have them all in a test folder inside the same package.
Your code belongs to different package if you move it into different folder.
This is how GO defines packages https://golang.org/doc/code.html#Organization:
Each package consists of one or more Go source files in a single
directory.
This is how your code structured:
main
| -- main.go (package main)
+ -- test
| -- main_test.go (package test)
It is idiomatic to keep tests in the same folder with code. It is normal if language or framework set some rules that developer has to follow. GO is pretty strict about that.
This is how you can organize your code:
main
| -- main.go (package main)
| -- main_test.go (package main_test)
| -- main_private_test.go (package main)
Often it makes sense to test code against its pubic interfaces. The best way to do that that, is to put tests into different package. GO convention is to keep tests in the same folder what leads to using the same package name. There is a workaround for that issue. You can add _test (package main_test) prefix to package name for your tests.
If, that is not possible to test your code using public interfaces, you can add another file with tests and use package main in that file.
I already using the minify argument when building with dart2js.
I looked at the output and I see that the import 'dart:html causes problems in terms of the output file size (2kb .dart file becomes 182kb .js file). For example it imports SVG package though in my code I never touch any <svg> DOM Elements.
I understand that the compiler doesn't know if I'm going to use svg DOM Elements or not. And I understand that the using of var is one of the reasons of that behavior.
But if I will not use any var keywords, the compiler still doesn't have enough 'power' to strip all unused packages and functions.
Is there any directive I can use to forbid the import of certain packages. I mean built-in packages right now. I'm using IntelliJ IDEA and it doesn't allow me to change anything in the Dart default setup.
UPD: Tried to use
import 'dart:html' show querySelector, Element
to import only that method and class, but file size is still 182kb.
The only solution I see for now is to make a few stripped versions of the default 'dart:html' package. The one without WebGL, SVG and some other features.
Because maybe Dart compiler works good, but there is just some methods and classes that I don't use, but the code uses. Like.. the initial package methods checking if some elements are SVG or something like that.
There is a tool for analyzing the output of a dart2js build, especially for references and dependencies. Just tested and gave a better overview in my case.
https://github.com/dart-lang/dump-info-visualizer
hosted :
https://dart-lang.github.io/dump-info-visualizer/
Build with option --dump-info
https://webdev.dartlang.org/tools/dart2js#options
Even when you don't import anything you will get some minimal output size. Dart provides a lot of features like classes with inheritance and mixins (and a lot more) and dart2js output contains code that implements these features.
This is like adding a JS library like jQuery.
Therefore main() {} will already result in an output size of several dozen kb. Adding another line of code probably will only add a few additional bytes.
pub build by default does tree-shaking and minifications, therefore no additional options are required.
Not having come from a C/compiled languages background, I'm finding it hard to get to grips with using Go's packages mechanism to create modular code.
In Python, to import a module and get access to it's functions and whatnot, it's a simple case of
import foo
where foo.py is the name of the module you want to import in the same directory. Otherwise you can add an empty __init__.py into a subfolder and access the modules via
from subfolder import foo
You can then access functions by simply referencing them through the module name, e.g. y = foo.bar(y). This makes it easy to separate logical pieces of code from one another.
In Go however, you specify the package name in the source file itself, e.g.
package foo
at the top of the 'foo' module, which you can then supposedly import through
import (
"foo"
)
and then refer to it through that, i.e. y := foo.Bar(x) . But what I can't wrap my head around is how this works in practice. The relevant docs on golang.org seem terse, and directed to people with more (any) experience using makefiles and compilers.
Can someone please clearly explain how you are meant to modularise your code in Go, the right project structure to do so, and how the compilation process works?
Wiki answer, please feel free to add/edit.
Modularization
Multiple files in the same package
This is just what it sounds like. A bunch of files in the same directory that all start with the same package <name> directive means that they are treated as one big set of code by Go. You can transparently call functions in a.go from b.go. This is mostly for the benefit of code organization.
A fictional example would be a "blog" package might be laid out with blog.go (the main file), entry.go, and server.go. It's up to you. While you could write a blog package in one big file, that tends to affect readability.
Multiple packages
The standard library is done this way. Basically you create modules and optionally install them into $GOROOT. Any program you write can import "<name>" and then call <name>.someFunction()
In practice any standalone or shared components should be compiled into packages. Back to the blog package above, If you wanted to add a news feed, you could refactor server.go into a package. Then both blog.go and news.go would both import "server".
Compilation
I currently use gomake with Makefiles. The Go installation comes with some great include files for make that simplify the creation of a package or a command. It's not hard and the best way to get up to speed with these is to just look at sample makefiles from open source projects and read "How to Write Go Code".
In addition to the package organisation, Like pip in python, use dep https://github.com/golang/dep for go package management. if you use it on existing go package it will automatically build the dependency tree with versions for all the packages being used. when shifting to production server, dep ensure will use Gopkg.toml to install all the required packages.
Just use dep ensure -add , other commands for dep are:
Commands:
init Set up a new Go project, or migrate an existing one
status Report the status of the project's dependencies
ensure Ensure a dependency is safely vendored in the project
version Show the dep version information
check Check if imports, Gopkg.toml, and Gopkg.lock are in sync
Examples:
dep init set up a new project
dep ensure install the project's dependencies
dep ensure -update update the locked versions of all dependencies
dep ensure -add github.com/pkg/errors add a dependency to the project
I'm starting to create a MSBuild scripts for my products, and I've encounter a dilema.
The code is divided into around 25 projects, some wll require obfuscation, some will require strong-name signing; others will require linking into a single file.
All these projects should result in 3 products, with 3 setups.
The question at hand is as follow: How do I divide the MSBuild scripts to make most sense?
Do I create a script for each product? do I create a script for each project? Do I have one script for building, another for obfuscation and so on?
I think this is good idea to have script per product.
To minimaze dublication create reusable "sub-scripts" and import them to main script (this could be done with Import directive).
<Import Project="..\Steps\Step1.proj" />
Script per product sounds like the way to go. You may want to consider having any number of shared or base scripts too, to import common build steps. Like Mike Chaliy already mentioned you can then use Import in your product's build script:
<Import Project="..\Shared\Base.proj" />
Another thing you might also want to take advantage of is target and property overriding. It's akin to overriding virtual methods in a .Net class. See the documentation and the MSBuild Team Blog for more details. I know I've taken advantage of this quite often by setting defaults in the included scripts then overriding them as necessary in the product build script in order to customize build behaviour. For instance I often have generated files that are required before the build so I hook those targets into the BuildDependsOn property group. This way my generated files are generated whenever I do an F5 from the IDE, call the build target from the command line or otherwise build the project or solution. Obviously if you have any build steps that run long or only need to be run in special circumstances (like building installers), you'll want to take care about exactly what gets hooked in.