I'm developing a ClojureScript library, which is intended to be used in a browser environment.
So obviously there will be additional source files during development and testing. How can this be separated from the library source?
Is there a way to mark some sources as just for testing purpose which would be omitted when installing / deploying the project?
Additionally the resources folder, which contains some HTML files (etc.), should not be included when publishing as well.
In your build.boot put only those files that you want in your final build to :source-paths.
Add your test files only when defining a test-setup task like this:
(deftask test-setup []
(merge-env! :source-path #{"dir_with_tests"})
indentity)
And use it in your boot test task:
(deftask test []
(comp
(test-setup)
(your-test-task)))
Related
I am new to automated testing. I am trying to set up a Maven project for my Selenium test automation work. I put all the packages pertaining to envVariables, library, settings, resultLog, errScreenshots etc under src/test/java.
I have a couple of questions here
i)I showed this framework to my developer and he asked me to move some of the packages under src/test/resources. I am not sure whether this needs to be done or whatever I have configured is correct. If I need to move the packages to resources folder, what packages should I move? Can somebody please advise me on how to configure this?
ii) what should the src/main/java folder contain? I thought it will contain the src code of my application and test folder would contain unit tests and selenium tests. But my developer says the test folder will contain only unit test that test the classes in the src/main/java. It should not contain my selenium tests. Can somebody please explain this to me?
Regards
vasu
I am not sure about the structure of your automation project. I prefer the following hierarchy in MAVEN projects
src
|-----main
| |-----java
| |-----Pages (contains application code arranged as one Class per Page)
| |-----Steps (calls the page objects and methods called in Pages)
|-----test
|------java
| |-----Test (Opens browser and calls steps to perform test - TestNG)
|------resources
|-----InputSheets
|-----Environment Variables
The results are saved in C or D drive and are time stamped to avoid getting overwritten.
The automation helper library is created as a separate Maven project and is added as a dependency to the test project. In this way the helper library is independent from the test project and can be used across all projects if need arises.
All this being said, much of the structure is a matter of choice and varies according to your project requirements.
"src/main/" is for production code or test automation framework, not for test cases. "src/test/" is for testing stuff, including selenium tests. "java" folders are for classes, "resource" folders are for configuration and test data.
I suggest creating a separate maven module for your testing stuff: test framework and test cases.
Please refer maven directory layout page for more information.
UPDATE: I have created sample maven project to show how run selenium test with selenide.
I have a PhoneGap project that use custom MSBuild scripts running in TeamCity as a CI build.
What I want to add now is zip and send the project files with the PhoneGap REST API on each check-in.
But before sending the files I need to make a few changes inside the head node of the index.html since there are URIs to a service that differs from DEBUG, TEST, RELEASE environments.
Is there any way I could use something like #ifdef with build properties on a .html file or is there perhaps an even better way of solving this scenario using MsBuild/TeamCity?
You could setup custom tokens (like "##replace this##") and then simply update HTML content using TeamCity PowerShell build step.
I have a solution in VS2010 and it has three project, two of these projects have web config file, the projects have web config transformation for each environment (dev, test and prod).
At the process for TFS build option, I have the at the MSBuild Arguments : /p:DeployOnBuild=True
Everything looks good, the drop folder, the zip files and all structure for the final deployment. The issue I am facing the web config for test and prod is not created correctly after the final deployment, I could see at the drop folders the file projectName.SetParameters.xml, it contains the values for development when the build has been QUEUE for Test and Prod. One of the project has the correct web config (test and prod) but the other project has always the dev webconfig.
Is it a bug in the MS Build? What am I missing in the build parameters?
When I create a build deployment package the web config transformation creates the correct web config file, no issues with this process, but I do not want to use build deployment package to deploy my solution.
Any help will be appreciated.
Thank you.
In your Build Definition you probably defined the Configurations to use. Part of that also defines something like Any CPU or x86. As it turns out the solution the Platform "Any CPU" has a space where in the project files the Platform Any CPU does not have a space.
I found the best way to get around this was to leave the Platform blank and only put in the configuration name. VS will pop up a warning letting you know that there is data missing, you can just hit "Yes" to save it anyways. Alternatively you can just type in your configurations like the following |Release,|Debug.
The pattern is [PlatformName]|[ConfigurationName],[PlatformName]|[ConfigurationName],...
Currently working on a PHP/HTML/JS project that is made up of a 'core' directory and multiple individual 'product' directories.
Dir structure as follows...
Core
JS
PHP
Product1
JS
PHP
build.xml
Product2
JS
PHP
build.xml
The ANT build script lies in each respective product directory. When triggering an ANT build, the core files are copied into a deploy directory, then the respective product files are merged into (and overwritten if necessary) the same directory. ANT then runs Qunit, PHPUnit tests, concatenates and minimizes the javascript etc. This new deploy directory is then copied to the CI environment.
My question is, is this the best way of doing this? Is there a way to introduce versioning of the core files - so product1 might use v1.2 of core files?
This method also causes problems when running the application locally - effectively on every change of a file, the build script needs to be run again.
Does anyone have any suggestions of how to improve this?
This pertains to Web Deploy and/or Web Deployment Projects (not sure what the relation is between those). Simply curious about the constituent Tasks that I might be able to recompose into a customized package Target.
The publishing targets for generating msdeploy web packages can be located at :
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets
In addition to playing with the tasks, there are a variety of properties you can use to redirect the packaging output name, location and configuration....