I have my folder structured like:
backend
|-Process1
|-Process2
|-app
|-config
|-controllers
|-models
public
|-css
|-js
Where should I put my unit tests folder?
For node projects, it's common to have a tests folder in the top level. For example, for my projects I usually have these folders:
bin (for bins)
lib (for my node.js library files)
test (for tests)
config (for config files, if necessary)
public or static (for static assets, if necessary)
node_modules (where npm-installed modules end up going)
For the most part it's not too critical how you organize the code as long as it's organized and has obvious entry points. Basically, you should be able to type "npm test" and have it work by reading the command from the package.json.
Related
I have a following project structure
bin
start.sh
db
liquibase_scripts
...
schema.json
main
java
...
test
resources
liquibase_scripts
...
schema.json
So than I build my project, folder db with liquibase scripts added to distributive.
In unit tests I use H2 database and want to load schema from db/liquibase. I create bean
#Bean
public SpringLiquibase springLiquibase() {
SpringLiquibase springLiquibase = new SpringLiquibase();
springLiquibase.setDataSource(dataSource());
springLiquibase.setChangeLog("classpath:/liquibase/sam.json");
return springLiquibase;
}
The problem is that method setChangeLog look at resource folder in test folder.
So to solve the problem I copied all liquibase scripts to the test/resources directory.
But this is not ok becouse now I have 2 copies of scripts in different folders.
Is there a way to force springLiquibase.setChangeLog find scripts in any folder not only in test/resources?
In Maven build configuration you can define testResources, which may be directories and files. It looks like this:
<build>
<testResources>
<testResource>
<directory>${project.basedir}/db/liquibase_scripts</directory>
</testResource>
</testResources>
</build>
With such configuration Maven copies the files into the target/test-classes directory. Thanks to that those files can be used as test resources in the code, but there's no duplication in the project files.
Im using such configuration (Liquibase + testResources) in one of my projects. To better reproduce your problem, I've created a separate branch, where you can find the configuration described above - see: this commit diff. All test pass after the change.
I have a project and there is a ./tests directory at its root containing several hundred MB of data that is used by the tests of several libraries:
./tests
./src/lib1/dune
./src/lib1/tests/dune
./src/lib1/tests/tests.ml
./src/lib2/dune
./src/lib2/tests/dune
./src/lib2/tests/tests.ml
...
I also defined tests that use the data in ./tests for each library like this:
(rule
(alias runtest)
(action (run ./tests/tests.exe)))
I now have to somehow communicate the location of the test data to each of my tests.exe. What is the most elegant way of doing this using dune?
It seems that dune copies my test data into _build which is unnecessary because the data never changes and it doesn't make sense to waste several hundred MB of space that way. From the documentation it seems that %{project_root} would contain the path to my source files but unfortunately, the variable evaluates to . which is useless for the tests which are run after a cd _build/default/src/libX and thus . does not point to the project root anymore. So is there a dune-way to specify the path to the original source directory without ugly hacks?
Right now, I'm using an environment variable containing the full path before I run dune runtest but is there a more integrated way?
I have not tried it myself but it sounds like the data_only_dirs stanza is what you are looking for: https://dune.readthedocs.io/en/stable/dune-files.html#data-only-dirs-since-1-6
How can I declare that the "root" folder for all deployment items are the .sln dir?
Seems like I work really hard with relative paths of deployment items
[TestMethod]
[DeploymentItem(#"..\..\..\MyTestFilesFolder\myFile.xml")]
public void Test_bla{}
Given that "MyTestFilesFolder" is near my .sln file (solution folder) I'd like to have
[TestMethod]
[DeploymentItem(#"MyTestFilesFolder\myFile.xml")]
public void Test_bla{}
How can this be achieved with tests of vs2013?
It seems you are not deploying the xml files with your unit tests. Go to the properties of the xml files and set the build action and to content and copy to output directory to copy always. Now the files are deployed to your test directory.
I am severely confused about where to put my templates files and static files.
I understand absolute and relative paths just fine, but I can't seem to find any instructions that mirror the installation I have. I know this resembles other questions, but those answers aren't working. The video I watched to successfully build a simple app didn't put templates in the Project folder, which is where logic tells me they should be.
I have Python at:
C:\Python27
Django (v1.6.5) at:
C:\Python27\Lib\site-packages\django
I created a project "mysite" and an app called "films."
Project "mysite":
C:\Python27\Scripts\venv\mysite
and an App "films":
C:\Python27\Scripts\venv\mysite\films
The video I watched had me put my templates at:
C:\Python27\Lib\site-packages\django\contrib\admin\templates
But this seems completely stupid because the templates are outside of both the Project and the App.
Shouldn't I put a templates folder in the Project folder:
C:\Python27\Scripts\venv\mysite\templates
And then create subdirectories using the App name?
What files do I need to edit (and how) to tell Django where to find them?
Follow a similar process for static files (css, images)?
Like all frameworks, django offers great benefits if you follow some guidelines (and give up some control). The trick is to know what these guidelines are.
For templates:
If the template is not tied to a particular application, put it in a templates directory at the root of your project. Add the full path to this directory to TEMPLATE_DIRS.
All other templates should go in a directory called templates inside your application directory. So if you application is called myapp, templates for myapp will go in myapp/templates/
For static files:
For files related to specific applications, inside your application directory create a directory called static, then inside it a directory with the name of your application. So, if your application is called myapp, you would have myapp/static/myapp. Place all your static content for this application here; for example myapp/static/myapp/js/funky.js.
For static files that are generic, create a directory called assets (or static) in the root directory of your project. Add the full path to this directory to STATICFILES_DIRS.
By default, django will search all applications listed in INSTALLED_APPS, and add any templates and static directories to its search path for files. This is how, by default, the admin works without you having to configure anything.
If you chose to place your templates and static files in some other location, only then do you need to modify the TEMPLATE_DIRS and STATICFILES_DIRS settings. If all your templates and static assets are tied to applications, just creating the directories as mentioned above makes everything work.
If you are wondering why you need to create another directory under myapp/static/ to store your static files, this is more for portability. The collectstatic command is a simply "copy and replace" utility. It will overwrite all files in the STATIC_DIR location. This means that if two applications have some static file with the same name, they will be overwritten without warning. Adding a subdirectory keeps your application's static assets from being overwritten, because the exact path will be created.
Suppose you have two applications, app1 and app2, and both have a file named style.css in their respected directories:
app1/static/css/style.css
app2/static/css/style.css
When you run collectstatic, you'll end up with the following (assuming static is the name of your STATIC_DIR setting):
static/css/style.css
This may be the style.css from app1 or app2, the other cannot be determined (its actually based on the INSTALLED_APPS order). To prevent this, if you have:
app1/static/app1/css/style.css
app2/static/app2/css/style.css
Now, you'll end up with:
static/app1/css/style.css
static/app2/css/style.css
Both files will be preserved.
You also shouldn't put your code in your virtual environment directory. The virtual environment is not part of your source code, and placing your project in the same directory may cause problems later.
Create a single directory for your environments - I call mine envs (creative, I know). Create all your environments in this directory. Once you activate the environment, you can work in any directory in your system and your shell will be configured for that environment's Python.
Finally for the best, accurate, most up-to-date information - always refer to the django manual and the tutorial. Almost all other resources (even the often suggested djangobook.com) are outdated.
I have not used Unit Testing so far, and I intend to adopt this procedure. I was impressed by TDD and certainly want to give it a try - I'm almost sure it's the way to go.
Boost looks like a good choice, mainly because it's being maintained. With that said, how should I go about implementing a working and elegant file-structure and project-structure ? I am using VS 2005 in Win XP. I have been googling about this and was more confused than enlightened.
Our Boost based Testing structure looks like this:
ProjectRoot/
Library1/
lib1.vcproj
lib1.cpp
classX.cpp
...
Library2/
lib2.vcproj
lib2.cpp
toolB.cpp
classY.cpp
...
MainExecutable/
main.cpp
toolA.cpp
toolB.cpp
classZ.cpp
...
Tests/
unittests.sln
ut_lib1/
ut_lib1.vcproj (referencing the lib1 project)
ut_lib1.cpp (with BOOST_AUTO_TEST_CASE) - testing public interface of lib1
ut_classX.cpp - testing of a class or other entity might be split
into a separate test file for size reasons or if the entity
is not part of the public interface of the library
...
ut_lib2/
ut_lib2.vcproj (referencing the lib2 project)
ut_lib2.cpp (with BOOST_AUTO_TEST_CASE) - testing public interface of lib2
...
ut_toolA/
ut_toolA.vcproj (referencing the toolA.cpp file)
ut_toolA.cpp - testing functions of toolA
ut_toolB/
ut_toolB.vcproj (referencing the toolB.cpp file)
ut_toolB.cpp - testing functions of toolB
ut_main/
ut_main.vcproj (referencing all required cpp files from the main project)
ut_classZ.cpp - testing classZ
...
This structure was chosen for a legacy project, where we had to decide on a case-by-case basis on what tests to add and how to group test-projects for existing modules of sourcecode.
Things to note:
Unit Testing code is always compiled separately from production code.
Production projects do not reference the unit testing code.
Unit Testing projects include source-files directly or only reference libraries, depending on what makes sense given the use of a certain code-file.
Running the unit tests is done via a post-build step in each ut_*.vcproj
All our production builds automatically also run the unit tests. (In our build scripts.)
In our real (C++) world you have to make tradeoffs btw. legacy issues, developer convenience, compile times, etc. I think our project structure is a good tradeoff. :-)
I spilt my core code up into either .libs or .dlls and then have my Boost test projects depend on these lib/dll projects. So I might end up with:
ProjectRoot
Lib1Source
Lib1Tests
Lib2Source
Lib2Tests
The alternative is to store your source in a separate folder and add the files to both your main apps project and the unit test project but I find this a little messy. YMMV.