I have a xUnit test subproject which includes a directory where test data files are store. Does xUnit provide any feature to access test data included with the source files?
I think you could just get the current directory:
var workingDirectoryPath = System.IO.Directory.GetCurrentDirectory();
This will give you working path like:
C:\Users\XXX\Documents\Visual Studio 2017\Projects\PROJECT_NAME\bin\Debug\netcoreapp2.2
Then traverse upwards to the test project directory. From there you can proceed to the test data directory and perform any operations you like.
Related
Please guide since i wanted to understand on the build tool maven 'directory structure' intelli j as IDE where main/test divided into two separate folders but both have the same files.
Ps- I recently moved into QA automation so want to understand it better.
FYI per maven main website:
a. The main directory is the root directory for source code related to the application itself, not test code.
b. The test directory contains the test source code.
Maven search for the files in the below directory structure.
src/main/java - Source Java files
src/main/resources - Source resource files
src/test/java - Test cases
src/test/resources - Test resource files
Maybe this site would be helpful to you: https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
Maven uses a strict folderstructure. Are you sure, that there are the same files in the folders? As Bhargav Kumar R mentioned before, in the test-folder there will be your test-classes, in the resource-folder there will be the resources for your tests.
I am trying to implement automated unit testing with each build using TFS.
Problem statement :
I have created few xml files which stores test data and set to copy always. When run locally files are picked up from bin folder. When I schedule a build, build process looks for files in out folder under TestResults on Build Server. Out folder contains ddls but not the xml files. Hence unable to find files and results into build failure partially.
You can specify additional files to deploy in your test settings file:
More details here - https://msdn.microsoft.com/en-us/library/ms182475.aspx
You could also use the DeploymentItem Attribute.
https://msdn.microsoft.com/en-us/library/microsoft.visualstudio.testtools.unittesting.deploymentitemattribute.aspx
I have some problems getting the code coverage .coverage file generated in nightly build.
What I have: I've configured my build to use a .runsettings file and Type of run settings : CodeCoverageEnabled
The build is correctly running all the required unit tests and measuring the code coverage, using only a selected number of assemblies (specified in the .runsettings file).
In the build report, within VS2013, I can manually export the code coverage file (a .coverage file).
What I need:
I would need to configure the build to automatically generate that .coverage file in a target folder.
How do I do that?
The .coverage file is present as a part of the test results. You can use the .runsettings to set a outputpath for the test results
<ResultsDirectory>c:\\TestResults</ResultsDirectory>
The .coverage file will be present in a subfolder within the results directory.
If you want to push it to another location you can do that via a post-build script in your nightly's build process template.
I have inherited a Go project that consists of a lot of common files, a library of sorts, two executables, and theoretically a test suite. The test suite is being written after the fact. But I dislike the only way I've found of setting up is rather unpalatable
I'm using Ginkgo, and this is my starting directory structure
component1/component1.go
component2/component2.go
cmd1/cmd1.go
cmd2/cmd2.go
project_suite_test.go
component1_test.go
Each cmd?.go file will be compiled into a separate executable.
What I would like is a multi-file test suite, usually one file per component. Where do I put the files so that go test will find and run all of them, without leaving them here in the root of the project?
ginkgo init and ginkgo bootstrap will set up your tests. ginkgo -r will run all your tests recursively.
Reason:
Ginkgo command will only work if you have actually bootstrap your project via ginkgo.
Options:
To use that you have to go to your test dir in terminal and run
ginkgo init : To Initialise project:
ginkgo bootstrap : This will generate new file with test suite config
ginkgo or ginkgo test : this will now be able to run tests based on your new generated file because that's what it is trying to search.
Alternatively:
If you like to keep your tests in a sub-folder, say test, then running
go test ./...
will attempt to run tests in every folder, even those that do not contain any test, thus having a ? in the subsequent report for non-test folders.
Running
go test ./.../test
instead will target only your test folders, thus having a clean report focused on your tests folders only.
you can alternatively use 'go run $(ls *.go)' to run all the files in a given folder.
Notice you have regular expression within () braces.
In-case you want to run test in different path update path as per your desired dir in the regular expression
You can use go test ./... in the root and it will go into child folders and execute the tests:
component1/component1.go
component1/component1_test.go
component2/component2.go
component2/component2_test.go
cmd1/cmd1.go
cmd1/cmd1_test.go
cmd2/cmd2.go
cmd2/cmd2_test.go
Inside my MsTests I have to reach and use a file in my project. So I am using Path.GetFullPath(#"......\name_of_file")
But when running the build I get a file not found error because the context of the path is the temp directory (C:\TeamCity\buildAgent\temp\buildTmp) instead of the checkout directory where all my files are (C:\TeamCity\buildAgent\work\e87255825b2f3eb1)
Is there a config to change that? Or a better way to do it?
I couldn't find a TeamCity option to specify the directory the unit tests should be run. Someone else might be able to help there.
However, I usually include files that are needed for the unit tests as embedded resources so that during execution you know for sure the file will always be accessible no matter where it is running from. You can easily get a Stream from an embedded resource and if you need to use an API that only takes a file name you can write the file to Path.GetTempPath().
I modified my tests to refer to the files like this:
string currentDir = new System.Diagnostics.StackFrame(true).GetFileName();
var workingFile = new FileInfo(currentDir);
string fileContents = File.ReadAllText(workingFile.Directory + #"\ResourceFolder\MyFile.xml");
I know this isn't a good way to do it, but this works for me locally and when called from TeamCity.