I'm writing some tests with xUnit in visual studio code.
Tests extract some sensitive data from Environment.
I'm storing those variables in .env file, in the workspace root folder.
If I load that file content in my shell and then issue dotnet test, tests runs correctly and use sensitive data extracted from environment.
In order to debug those tests, I'm setting envFile parameter in launch.json like this:
This usually works in a console application, but not when I debug a test through the VSCode Debug button:
The content of my .env file (in the workspace root, next to .csproj) is:
TEST_VAR=aaaa
Is this the expected behaviour?
Thanks.
Update:
In the end I changed approach. If you are interested in a different (and more powerful) solution, I described it in this article
Related
I have a legacy code base which has CMake configuration and .sh files which calls build commands with respect to build type ( release, relwithdebinfo etc.) as well as does a lot of things.
I have to work over codebase. So far I used STM32CubeIDe. I imported the project as existing Makefile project and then I changed C/C++ Build directory to where makefile outputs converted.
So whenever I did a change on the code, I hit the build command over UI and it calls make command at where I modifed the path above.
This is working but In case of a need of debug then I had to use .elf outputs and OZONE J link Debug program.
I have to do build+debug in same environment but eclipse is slow and making me struggle.
How can I make VSCode host to my legacy code in order to build and debug and also navigate in code i.e go to the definition of code in VSCode, not only building.
Please navigate me if anything needs to share from existing code base, if there is still unclear.
I wrote some java code in eclipse - this code reads files that are in src/main/resources/input and it writes files to src/main/resources/output. When I run locally (or debug), this code works exactly as I expect - the files open successfully, I can read the data I need, and I can write the data I need to write. Then I copied the code into a new project with VS Code (I want to start using VS Code instead of eclipse). I have the project set up as needed, including all the typical plugins for java development, but when I debug the code in VSCode, it fails to find the input file (FileNotFoundException). Same code, same file location, same file name.
The same behavior happens when trying to write to the files - Eclipse works fine, VSCode gets a FileNotFoundException.
Is there something I need to do in VSCode so that it can find the files?
Thank you for any help you can provide.
SRJ
I'm having more trouble than I'd like to admit to structure a simple project in Python to develop using Visual Studio Code.
How should I structure in my file system a project that is a simple Python package with a few modules? Just a bunch of *.py files together. My requisites are:
I must be able to step debug it in vscode.
It has a bunch of unit tests using pytest.
I can select to debug a specific test from vscode tab and it must stop in breakpoints.
pylint must not show any false positives.
The test files must be in a different directory of the main module files.
I must be able to run all the tests from the console.
The module is executed inside a virtual environment using python standard lib module venv
The code will use type hints
I may use another linter, even another test framework.
Nothing fancy, but I'm really having trouble to get it right. I want to know:
How should I organize my subdirectory: a folder with the main files and a sibling folder with the tests? Or a subfolder with the code and a subsubfolder with the tests?
Which dirs must have a init.py file?
How the tests should import the files from the module? Should I use relative imports?
Should I create a pytest.ini file?
Should I create a .env file?
What's the content of my launch.json the debugger file config in vscode?
Common dir structure:
app
__init__.py
yourappcode.py
tests (pytest looks for this)
__init__.py
test_yourunittests.py
server.py if you have one
.env
.coveragerc
README.md
Pipfile
.gitignore
pyproject.toml if you want
.vscode (helpful)
launch.json
settings.json
Or you could do one better. Ignore my structure and look at the some of famous python projects github page. Like fastAPI, Flask, asgi, aiohttp are some that I can think of right now
Also:
I think absolute imports are easier to work with compared to relative imports, I could be wrong though
vscode is able to use pytest. Make sure you have a testing extension. Vscode has a built in one im pretty sure. You can configure it to pytest and specify your test dir. You can also run your test from command line. If youre at the root, just running ‘pytest’ will recognise your tests dir if it’s named that by default. Also your actual test files need to start with prefix test_ i think.
The launch.json doesn’t need to be anything special. When you click on the settings button next to play button in the debug panel. Vscode will ask what kind of app is it. I.e If its a flask app, select python then select flask and it will auto generate a settings file which you can tweak however you want in order to get your app to run. I.e maybe you want to expose a different port or the commands to run your app are different
It sounds to me like you just need to spend a bit of time configuring vscode to your specific python needs. For example, you can use a virtualenv and linting in whichever way you want. You just need to have a settings.json file in the .vscode folder in your repo where you specify your settings. Configurations to specify python virtualenv and linting methods can be found online
I have some unit tests in my project that needs runsettings file to run properly.
When I launch those tests, I have issues with parameters that should be taken from the runsettings file
My question is how can I pass the runsettings file to visual studio code in order to use it when I execute my tests ?
Thank you in advance,
Regards
Two parts need file .runsettings when you work with VS Code:
when build tests in VS Code, it firstly run vstest.exe with parameters
when run tests in VS Code, it need mstest.exe.
For the first part, here is the document for .NET Core Test Explorer:
https://github.com/formulahendry/vscode-dotnet-test-explorer
The settings are available via File / Preferences / Settings. Navigate
to extensions and .NET Core test explorer.
Additional arguments that are added to the dotnet test command. These
can for instance be used to collect code coverage data
("/p:CollectCoverage=true /p:CoverletOutputFormat=lcov
/p:CoverletOutput=../../lcov.info") or pass test settings
("--settings:./myfilename.runSettings")
But above settings are global, you can setup from .vscode\workspace.code-workspace file for specified test project only:
{
"folders": [
{
"path": ".."
}
],
"settings": {
"dotnet-test-explorer.testArguments": "--settings .runsettings",
"dotnet-test-explorer.testProjectPath": "**/test.project.name.csproj"
}
}
For the second part, we need a new feature RunSettingsFilePath that's delivered from VS 2019 16.4.
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<RunSettingsFilePath>$(MSBuildProjectDirectory)\.runsettings</RunSettingsFilePath> // or $(SolutionDir)
</PropertyGroup>
...
</Project>
If you're using the C# extension for VS Code, there's a setting to configure your .runsettings file. Go into VS Code's settings and search '.runsettings'. This should show the "Omnisharp: Test Run Setting" setting under the Extensions > C# configuration node.
I suggest clicking on the "Workspace" tab, so the setting is stored in your project instead of your user. That way, you can also check these settings into git.
I'm trying to get MSTest.exe to run, and it seems like testcontainer isn't being read properly; while my tests all run successfully in all config environments within Visual Studio.
the command I'm using is:
"C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\MSTest.exe" /nologo /usestderr /testSettings:"C:\temp\MyProject\Sources\MyProject\Local.testsettings" /searchpathroot:"C:\temp\MyProject\Binaries" /resultsfileroot:"C:\temp\MyProject\TestResults" /testcontainer:"C:\temp\MyProject\Binaries\MyProject.Services.Server.UnitTests.dll"
The project references within testcontainer project look like this:
<ItemGroup>
<ProjectReference Include="..\..\Services\MyProject.Services.Server\MyProject.Services.Server.csproj">
<Project>{92EC1999-CC0C-47DD-A4D6-17C3B1233C50}</Project>
<Name>MyProject.Services.Server</Name>
</ProjectReference>
<ProjectReference Include="..\..\SvcConfiguration\MyProject.ServiceConfiguration.Interfaces\MyProject.ServiceConfiguration.Interfaces.csproj">
<Project>{8E2E7BA9-75DB-458E-A184-AC1030EAD581}</Project>
<Name>MyProject.ServiceConfiguration.Interfaces</Name>
</ProjectReference>
<ProjectReference Include="..\..\SvcConfiguration\MyProject.ServiceConfiguration.Services\MyProject.ServiceConfiguration.Services.csproj">
<Project>{39514766-23A8-45DB-96EA-B6B4D9C8B086}</Project>
<Name>MyProject.ServiceConfiguration.Services</Name>
</ProjectReference>
</ItemGroup>
Neither the ServiceConfiguration.Interfaces nor the ServiceConfiguration.Services DLL is placed into the Out folder in TestResults.
The project GUIDs do match between the references and the referenced projects.
Is there something that I'm missing in the command line?
mstest.exe will not coy all referenced dll's.
See a blog post on this at https://web.archive.org/web/20111221110459/http://www.dotnetthoughts.net/2011/11/22/mstest-exe-does-not-deploy-all-items/
You can specify exactly what files are copied to the test directory using a test settings file. You can create multiple test settings files in Visual Studio, so you can have one for running from VS, another for running from MSTest, another for server CI builds, and so on. See here for more information: Create Test Settings to Run Automated Tests from Visual Studio
Use the /testsettings:<filename> option to specify it on the command line.
What seems to confuse people at first is that, by default, MSTest's "current directory" is not the MSTest launch directory, but the Out folder of the test results.
As mentioned previously, MSTest does not correctly infer all used assemblies, if you don't have a direct reference, it will not copy the assembly. That said, Visual Studio has similar behaviour in its build too, so a lot of people work around this by adding bogus code references - a terrible solution - I don't recommend it.
However, native DLLs are even more problematic, and I have found that explicitly copying them in the test configuration (test settings) works for them, just as for managed assemblies.
Whether it goes to Out or the build area depends on different factors, however, for the situations where it still doesn't work, you can use a DeploymentItem "hack", or, tweak your runsettings file.
Try looking at this answer: https://stackoverflow.com/a/33344573/2537017