I'm using Cypress for client e2e testing and #cypress/code-coverage for reports. I have a monorepo, client and server folders. Each one generates its own coverage report (lcov.info). I am using CodeClimate for keeping track o total coverage. It provides a tool to merge multiple reports into one, and then upload it
The problem is that both reports have relative paths (regarding the tested files) to is service, so /client/coverage/lcov.info does not build path as 'client/component/index.ts' but /component/index.ts so report merging fails
I can fix this on the server side passing some options to jest-conf, but I didnt fine nothing related to cypress. I can generate the report folder/files in the root level passing an option to nyc (which is used under to hood by #cypress/code-coverage), but the paths are still relatives to the client folder.
Has anyone experienced this issue? Help much appreciated
Related
I am searching for any coverage report host/service/web which can visualize coverage for generated files.
I am currently using coveralls.io and it seems that it can not handle generated files and I do not know how to post them to coveralls.io so they can be viewed.
Source Not Available
The file "..." isn't available on github.
Either it's been removed, or the repo root directory needs to be updated.
https://coveralls.io/builds/25612947/source?filename=include/hdlConvertor/verilogPreproc/verilogPreprocParser/verilogPreprocParserBaseVisitor.h
Generated files may change build to build and are very large and I simply can not add them to git. But I need to know the coverage.
Currently I am only able to watch coverage for generated files locally.
I know the list of generated files and I can upload them during the build If I know where.
When we build our MVC app, we have a build process that pushes the site on to our UAT box.
Once published, We would like to run an automated tool that crawls all the links in the app and checks for broken links and any other issues (such as usability/accessibility, etc.)
What tool(s) exists that will crawl a site and generate a report a report on broken links, etc.?
Can it be integrated in to our CI (TFS) Build?
In the absence of any alternative advice, we went with this solution:
http://wummel.github.com/linkchecker/
It's working well for us. One of the key advantages of this system is that it has a command-line mode with lots of options AND it can produce multiple format reports (HTML, Sitemap, CSV, XML) in a single crawl. Other tools I've used in the past had to run multiple times, consuming more bandwidth and time.
The beauty of this is that we can add it to our build process and then automate the output. When the build is pushed to UAT, LinkChecker runs. When it has finished, the HTML output is emailed to us and the XML output is parsed. All 404 errors are raised as bugs in TFS.
Quite a nice solution.
I have been using MTM for a time and, so far, so good. I am trying to get Code Coverage over the tests I am executing. I have set my controller with 2 machines: 1 webclient and 1 webserver. For the webserver rule, i have configured code coverage. Of couse the webserver machine is the one that has my application running on IIS.
When I fire my automated tests (that btw were not created using visual studio, it was created using Ranorex) I can see that its generated an .coverage file.
But when I open this file, it is empty and I get this message from Visual Studio:
Empty results generated: No binaries were instrumented. Make sure the tests ran, required binaries were loaded, had matching symbol files, and were not excluded through custom settings. For more information see http://go.microsoft.com/fwlink/?LinkID=253731
Of course I have read
http://go.microsoft.com/fwlink/?LinkID=253731
http://msdn.microsoft.com/en-us/library/vstudio/hh698492.aspx
http://msdn.microsoft.com/library/jj159523.aspx
But I have found nothing wrong in my scenario.
Does anyone have any idea what could be happening?
Go and check if you find one of the following files in your solution: Local.testsettings or TraceAndTestImpact.testsettings and double click them in VS. A new window will open, there you need to select Data and Diagnostics. There you'll see a point Code Coverage, double click it and then select all the assemblies that you want to be code coveraged.
If that does not work, check if your PDB files are present next to your DLL files.
Well. It turned out to be a problem with the permissions of the user I was using to run the test agent on the web server.
After changing the user to another one who has more permissions everything worked fine.
We have a set of user acceptance tests (written in MSTest) which run fine locally, they're referring to some test files which the acceptance tests load in and process.
However, when running on team build (TFS 2010) the path to the files we're using is obviously different and the file cannot be found. This is still the case with using relative paths as the depth at which the local tests happen is different to the depth at which they happen on the build server.
What's the best way to refer to a file in tests so that it works both locally and during team build test runs.
I've considered putting them in the team project but I don't even know what the path to that will be.
Any ideas much appreciated!
Try the [DeploymentItemAttribute][1]
I have a vcproj file that includes a simple pre-build event along the lines of:
Helpertask.exe $(ProjectDir)
This works fine on developer PCs, but when the solution is built on our TFS 2008 build server under MSBuild, $(ProjectDir) is either blank or points to an unrelated folder on the server!
So far the best workaround I have managed is to hard code the developer and server paths instead:
if exist C:\DeveloperCode\MyProject HelperTask.exe C:\DeveloperCode\MyProject
if exist D:\BuildServerCode\MyProject HelperTask.exe D:\BuildServerCode\MyProject
This hack works in post-build steps but it doesn't work for a pre-build step (the Pre-build task now does nothing at all under MSBuild!)
Do you have any ideas for a fix or workaround? I have very little hair left!
$(MSBuildProjectDirectory) worked for me
I think your problem may be related to how items are initalized. An items include attribute is evaluated at the begining of a build. So if you depend on files that are created in the build process you must declare these as dynamic items. Dynamic items are those defined inside of a target, or by using the CreateItem task. I've detailed this on my blog MSBuild: Item and Property Evaluation.
Sayed Ibrahim Hashimi
My Book: Inside the Microsoft Build Engine : Using MSBuild and Team Foundation Build
I think the problem is that build server's workspace probably isn't initialized properly.
I just kept getting problems with this - I tried many different approaches but they all failed in mysterious ways.
Once $(ProjectDir) started behaving properly again, the pre-build step stopped executing the command (I added echo commands above and below it - they were both executed, but the program in between them was not. No errors or output of any kind were generated to indicate why it failed).
I don't know if this is a dodgy server of if MSBuild is having a laugh.
I've given up now. I gave the build server a big kick and have changed tack: We now run this tool offline (manually) and check in the results for the build server to use. So much for an automated build :-( If only MSBuild would run solutions in the same way as Visual Studio does - it's maddening that it sets up the environment completely differently (different paths coming out of the solution variables, ouptus redirected into different folders so you can't find them where they're supposed to be, etc)
I branched an existing project and $(ProjectDir) kept the old directory in the newly branched code. But that's because I had some compiling errors. Once every project in the solution compiled without errors, $(ProjectDir) changed to the correct path.
Carlos A Merighe