The documentation for the ember-cli-code-coverage project on Github does not clearly state how exactly to configure and run coverage reports.
The documentation hints that, after installing the addon, you just need to set an environment variable named COVERAGE to true. I interpret that to mean an environment variable in config/environment.js. After running the CLI command ember test I expect to find something saved in a coverage folder at the root of the project, but nothing appears to be generated. My tests run okay without any errors, and with all passing tests.
There are a few statements on Stackoverflow (here, here, and here) that suggest the package works okay. Searching for clear examples or how-to articles appears to be a dead end at the present moment.
I'm trying to get this working using versions:
Ember.js 2.6.0
ember-cli-code-coverage 0.2.2
Windows 10
You need to set the environment variable in the command line environment, not the Ember environment. Run COVERAGE=true ember test.
Side-note: this does seem like a weird choice, requiring a command line environment variable instead of making it configurable in other ways the way ember-cli-blanket does.
Related
I am pretty new to unit testing, and I am trying to understand best practice for whether and, if so, how to run Jest alongside webpack.
For context, I am used to using ESLint in the following way. I use eslint-webpack-plugin and configure it so that webpack outputs an error and/or fails the build if there is a linting error. I use this setup for both the development build (using webpack-dev-server) and the production build so that I can be made aware of and address linting issues as they arise. I also use lint-staged and husky to set up a pre-commit hook that runs ESLint before commits for a similar reason.
So, my inclination when learning Jest was to use a similar setup, where tests will be run as part of the webpack compilation process and errors will be obvious and intrusive so that I can address/resolve them as they arise. I tried following the tutorials for Babel and webpack on the Jest site, but I cannot get webpack to throw any errors, and I'm not even sure if it's even running Jest at all to be honest. I looked to see how create-react-app and create-next-app have Jest set up. They both include an npm script for testing, but it seems users are supposed to run that script manually, separately from the dev/build processes, or as part of a CI workflow.
Any advice appreciated!
So i'm starting use Intern for functional tests, so far so good I did it all, unit and functional tests.
I followed their intern-tutorial
Whenever you need to run a full test against all platforms, use the test runner. When you are in the process of writing your tests and want to check them for correctness more quickly, you can either use just the Node.js client (for unit tests only) or create an alternate configuration file that only tests against a single local platform, like your local copy of Chrome or Firefox (for all tests, including functional tests).
I searched on their documentation, but I didn't find anything exactly about local "tunnels".
I'm using Intern with Gulp, my localhost is localhost:3000 and I want to test on my Chrome 54 on Mac.
Thank you
I guess NullTunnel is what you're looking for?
I found the answer. I had to change the tunnel to Local Selenium.
Download the latest version of ChromeDriver
Set tunnel to 'NullTunnel'
Run chromedriver --port=4444 --url-base=wd/hub
Set your environments capabilities to [ { browserName: 'chrome' } ]
Run the test runner
Obs:
Don't forget to copy the chromedriver file to your project root.
I had to run on my project root .\chromedriver --port=4444 --url-base=wd/hub
The test runner has to be run in a new command line/terminal/shell
Hope to help someone that had the same issue.
I have been just starting out with ember addon and one of the difficulty I am facing is to debug it. I have a separate repo for my addon(lets name it my-addon for now), and everytime I make any change, I have to
1) commit it
2) push the changes
3) go to consuming app and then re install the app from git(atleast re-run npm install git:address so I get the latest changes)
4) run ember g my-addon (because I am in older cli)
5) do build
6) and check if things are working
This process is kinda tedious, I was wondering if I can place the addon(all of it) within the consuming app itself, atleast in the dev phase so I can just build my ember app and test the addon in the consuming app itself, and once I feel good about, push it to my local git repo.
Any thoughts or approach on how you folks do it - or may be I am just missing out something and doing it wrong!
Thanks,
Dee
If you use ember-cli you can link your local addon in the consuming app. You can find all details in the user guide
Note that watchman doesn't observe local addon symlinked (there are couple of issues opened both on ember-cli and watchman). I've resolved removing watchman falling back to NodeWatcher (I'm on mac)
I am pretty sure the solution provided by #GUL must work too, but what worked for me was:
1) in the consuming dev app, I created a folder called addons and placed all my addon code there
2) in consuming dev app, in package.json I added :
"ember-addon": {
"paths": [
"addons/ember-chart"
]
}
and that worked for me!
The top answer is best here. I just wanted to offer an alternative that is useful in certain situations. npm pack at root of in development addon. Then cd back to parent project. npm install ../ember-composable-helpers-2.2.0.tgz. And then check if things are working.
npm pack will create a tarball as if published on npm.
Question: What is the best solution for executing a 'mvn deploy' such that the deploy part is only run after all unit tests succeed and no processing steps are duplicated?
I was hoping the simple answer was: Execute maven command 'x' (or use a flag) such that the deploy can be run without invoking the prior goals in the default lifecycle.
Sadly this does not appear to have a simple answer. I have included the details on the path I have followed so far below.
We have the following three requirements:
Execute the maven deploy goal to deploy all multi-module artifacts to a remote repository.
Only deploy if ALL unit tests across all projects pass.
Do not repeat any processing.
We started with simply "mvn clean deploy", however we noticed a couple issues:
the build would stop before completing all unit tests :: so we added the --fail-at-end flag
The deploy goal would execute against any modules that were successful.
This results in a "corrupted" state where the remote repository may only has a partial deployment (if there were modules with failures later in the build).
We looked at 3 different solutions:
Staging the artifacts prior to deploying :: this was determined to be too heavy for a fully automated process.
Use a profile to override the default lifecycle such that 'mvn deploy -Pci-deploy' would run without invoking any prior goals :: this worked and was fast, but is obviously an unconventional approach.
Simply running 'mvn clean package' and then only iff successful execute 'mvn deploy' :: this appears to work and seems to only take a minor hit when the goals are invoked (though some of them are smart enough not to reprocess an unchanged workspace)
I pose this question to the community with the background details I have provided to determine if there is a better approach or a strong opinion regarding (potentially) making one of the following requests:
A new deploy goal that can run separate and apart from all other lifecycle goals with the expectation that: all prior steps have already been run and that it will execute the deploy identically to "mvn deploy"
a flag in the deploy goal which would effectively disable the previous goals.
a little more out of the box and definitely against the current convention:
a flag that would tell maven to run the [unit] test goal for all modules prior to proceeding.
Notes:
We are using Jenkins, but for the purposes of this question the CI environment is not the complication.
I tried the 'mvn deploy:deploy' goal, but it had a number of unclear errors.
I have not considered integration tests as part of the requirements.
Update 8/20/2013
I tested the deferred deploy plugin and determined that the tool worked as expected, but took way to long.
For our code base:
mvn clean deploy: for all goals executed in 2:44
mvn clean install 'deferred-deploy-plugin': for all goals executed in 15 min
mvn clean package; mvn deploy -Pci-deploy a custom build profile that disables the earlier goals executed:
for all goals (including deploy): 4:30
deploy only: 1:45
mvn clean package; mvn deploy -Dmaven.test.skip=true on the same workspace executed:
for all goals (including deploy): 4:40
deploy only: 1:54
The clean package followed by deploy skipping the tests runs faster than the deferred deploy and accomplished our desire to delay the deploy until after the tests succeed.
There appears to be a minor time hit for when the deploy lifecycle executes and exits each of the preceding goals (process, compile, test, package, etc). However the only alternative is to hack a non-standard execution, which only saves 10 seconds.
There's a new answer now. Since version 2.8 of the maven deploy plugin there's a way to do this "natively". See the jira issue for details.
Basically you need to force at least v2.8 of the plugin
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-deploy-plugin</artifactId>
<version>2.8</version>
</plugin>
and use the new parameter deployAtEnd. more info here. This setting usually goes along with installAtEnd of the maven-install-plugin
As an alternative, I also found this
http://code.google.com/p/maven-deferred-deploy-plugin/
A maven plugin that iterates through all projects in a reactor and
executes a deploy on each project individually. Can be used to produce
a near-atomic build for a reactor by deferring artifact deployment
until the install phase has completed.
Sounds alot like what you were asking for. I still think my other answer is easier to implement since you use jenkins, just check a checkbox
Two things.
Disabling all the previous phases i don't see it as an option. It is a basic feature of maven, you would be altering the standard lifecycle so i highly doubt anyone would implement something in a plugin to allow this
Since you said you use Jenkins, there is a setting in jenkins specifically for the case of deploying at the end to guarantee that the repo is not in a corrupt/intermediate state
In "Post-build actions"
Deploy artifacts to a Maven repository. In comparison with the
standard mvn deploy, this feature allows you to deploy artifacts after
the entire build is confirmed to be successful.
This prevents a typical problem in Maven, where some modules are deployed before a critical failure is discovered later down the road,
rendering the repository state inconsistent.
Note that regardless of this configuration, you can always manually come back to Jenkins and deploy any of the past artifacts to
any repository of your choice, after the fact.
To use this feature you shouldn't deactivate the automatic artifact archiving.
I have never used this so i can't confirm whether it works, I just know it's there for this particular use-case
I'm using Hudson for the expected purpose of testing our Django application. In initial testing, I would deploy Hudson using the war method:
java -jar hudson.war
This worked great. However, we wanted to run the Hudson instance on Tomcat for stability and better flexibility for security.
However, now with Tomcat running Hudson does not seem to recognize previously-recognized Python libraries like Virtualenv. Here's an output from a test:
+ bash ./config/testsuite/hudson-build.sh
./config/testsuite/hudson-build.sh: line 5: virtualenv: command not found
./config/testsuite/hudson-build.sh: line 6: ./ve/bin/activate: No such file or directory
./config/testsuite/hudson-build.sh: line 7: pip: command not found
virtualenv and pip were both installed using sudo easy_install, where are they?
virtualenv: /usr/local/bin/virtualenv
pip: /usr/local/bin/pip
Hudson now runs under the tomcat6 user. If I su into the tomcat6 user and check for virtualenv, it recognizes it. Thus, I am at a loss as to why it doesn't recognize it there.
I tried removing the commands from a script and placing it line-by-line into the shell execute box in Hudson and still same issue.
Any ideas? Cheers.
You can configure your environment variables globally via Manage Hudson ->
Environment Variables or per machine via Machine -> Configure ->
Environment Variables (or per build with the Setenv plugin). It sounds like
you may need to set the PATH and PYTHONPATH appropriately; at least that's the
simple solution.
Edited to add: I feel as though the following is a bit of a rant, though not really directed at you or your situation. I think that you already have the right mindset here since you're using virtualenv and pip in the first place -- and it's not unreasonable for you to say, "we expect our build machines to have virtualenv and pip installed in /usr/local," and be done with it. Take the rest as you will...
While the PATH is a simple thing to set up, having different build
environments (or relying on a user's environment) is an integration "smell".
If you depend on a certain environment in your build, then you should either
verify the environment or explicitly set it up as part of the build. I put
environment setup in the build scripts rather than in Hudson.
Maybe your only assumption is that virtualenv and pip are in the PATH (because
those are good tools for managing other dependencies), but build
assumptions tend to grow and get forgotten (until you need to set up a new
machine or user). I find it useful to either have explicit checks, or refer to
explicit executable paths that are part of my defined build environment. It is
especially useful to have a explicitly defined environment when you have
legacy builds or if you depend on specific versions of your build tools.
As part of builds where I've had environment problems (especially on Windows
with cygwin), I print the environment as the first build step. (But I tend to
be a little paranoid proactive.)
I don't mean to sound so preachy, I'm just trying to share my perspective.
Just to add to Dave Bacher's comment:
If you set your path in .profile, it is most likely not executed when running tomcat. The .profile (or whatever the name is on your system) is only executed when you have a login shell. To set necessary environment variables, you have to use a different set of file. Sometimes they are called .env and they exist on global and user level. In my environment (AIX), the user level .env file can have a different name (name is set in the env variable either in global environment file (eg. /etc/environment) or by parameter, when starting the shell).
Disclaimer: This is for the IBM AIX ksh, but should be the same for ksh on other systems.
P.S. I just found a nice explanation for .profile and .env from the HP site. Notice that they speak of a login shell (!) when they speak about the execution of the .profile file.