Why many repos have a test folder in it?
https://github.com/openstack/swift
https://github.com/openstack/openstack-helm
what's the test folder's function?
how it works?
A folder named test has no special connotation within Git or GitHub. However, it is a common and descriptive name for folders housing unit tests. Unit tests are of course not the only thing you can put there. One might store tests of an entire program or anything at all.
In terms of function, a number of programs provide test drivers to run each program and report what does and doesn’t fail. For example, autotools uses the check target of make to run tests. It’s just a folder, so you can do anything with it.
Related
I build my runner and it works fine. However, when it initializes, it first clones the project to /home/user/builds/xxxx... I never, ever, ever want GitLab to use /home. Never. Not for anything. I was told that it is impossible to change it to a different location. I find it hard to believe.
See in the image below, it gives me a warning about templates not found in some made up directory, then clones the entire project under the user's home directory. I don't give it that command - so it must be a default. Is there a way to choose ANY other mount point? The project is several hundred gigabytes and the /home directory is 50k. I cannot control that. So to a different mount point it must go.
I can provide the yml etc, but this is about core behavior of the runner itself - not anything I created. I'm hoping it is a simple variable I can send when initializing the runner.
Thank you in advance.
In the Jest documentation for React Native and in the generated projects I see a dedicated __tests__ folder outside of the main src folder.
However I prefer colocating unit tests with the actual production code, like this:
/src/App.tsx
/src/App.test.tsx
The benefit for me is to
see if a file has tests already
easily move components/code with their tests during refactoring
In the latter case I tend to completely forget about things in __tests__ folder).
Question
Is configuration necessary (or possible) for colocating the tests in the above fashion but not getting them bundled in the final apk?
Sure! The final architecture decision is yours. Try adding the folders you want to exclude in a .npmignore, like described here.
No matter how I set my build configuration for running my tests the go test tool is always run with ./...
E.G.
runs:
go test -v -cover ./... -run ./svs
Depending on what you need to run you can select different configuration types.
For the one in your picture, Run Kind Directory is selected and that means the IDE will run the tests in the directory you point it at and since the working directory is in the same directory, it will run ./... as that's what it means.
For the Run Kind Package, it will run only the specified package and no other packages, so no /... appended to it.
For the Run Kind File it will run the tests in a single file.
The pattern that you've added, ./svc tells the go tool how to match test names. There you should put valid patterns for test names. If you want to control for which directory / package the tests are run you can use a different run configuration per directory / package since multiple configurations are possible.
Based on your reply you want to run the tests in your whole projects, recursive, without the vendor folder. To do so, create a Run Kind Directory, as you have one already, and make sure sure you are using Go 1.9 as it will automatically ignore the vendor directory when using ./... matching.
Please let me know if you need further details.
I am writing code that creates a folder/file structure in ocaml, and I want to write some tests for it. I'd like to not have to create and delete files each time the tests are run, since they cna be run many times.
What would be the best way to go to mock filesystem? I'd be open to have a filesystem in memory or just mock up functions.
Maybe you could use a Makefile to help you.
For instance make test might start by compiling your program, then create the files and folders required for testing, launching your program, and then cleaning the test folder if need be (at that time, you might also want to check if the state of the test folder is as expected).
On linux:
mount -o size=50m -t tmpfs none ./ramdisk
will create a filesystem in ram, size 50M, mounted to ./ramdisk. Only root can do this. Non-root users can use it. It will show up in df and du. You can clean it by doing umount ./ramdisk.
Creation, usage and removal are working just fine, maybe the root requirement is an obstacle.
I checked quite a few similar questions, but so far I am unsatisfied with the solutions.
Ever use the Minecraft Server? At initial launch, it creates all the files and folders it needs, and allows you to make changes to files like Server.properties and ops.txt by making them external of the executable jar file.
I'm working on a similar project, and I want to duplicate that behavior. Everything works great when I run it in eclipse. When I export to a jar file though, things get funky. The external files and folders are created without a hitch, but afterword, it would appear as though they cannot be read from or written to. Any ideas how Notch made his server?
--edit--
Scratch that, it doesn't even appear to reliably create the files and folders. Maybe it only creates them the very first run after creation?
--edit again--
It creates them in the root directory. When I tested it in eclipse, the root directory was limited to the folder containing the project, and therefore looked fine. The solution was to make the class aware of it's location, and include it in all file operations.
Have the main class in your executable jar file look up where it is, then have it store that information in a global String or something. Prefix your filenames with that string in your file operations, and voila! It's writing to the correct directory.