I want to run my main application Codeception tests and have it automatically go through the tests provided by 3rd party modules (assuming they come with their own Codeception configurations) installed through composer (which means they are living in the vendor/ folder).
I don't know how this can be done. Do I need to provide some kind of Codeception run parameters? Do I have to modify the bootstrap files? Does Codeception even support something like this?
Codeception can include other test suites by using include setting in codeception.yml
Documentation: http://codeception.com/docs/08-Customization
Example:
include:
- vendor/vendor1/lib1
- vendor/vendor1/lib2
- vendor/vendor2/lib3
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)))
I am using Specflow and firing the nunit-console.exe in TeamCity to run tests as follows:
"C:\Program Files (x86)\NUnit 2.6.4\bin\nunit-console.exe" /labels /include:regression out=TestResultRegression.txt /xml=TestResultRegression.xml /framework=net-4.0 .\MyTests.dll
How can I access the NUnit include tag (/include:regression) so that I can call certain methods or properties for test setup (ex. If include = regression, then run this certain pull these certain test case ids from the app.config file where the key is "regression")
There is no way in NUnit for you to know what runner is running you or how it is doing it. This separation of concerns is by design. You could, of course, access the command line that ran the tests and examine it, but I think that again forces the tests to know too much about their environment.
Best solution is to organize tests hierarchically so that all tests requiring a certain setup are in a namespace or fixture where that type of setup is performed.
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 project that need to be deployed into multiple environments (prod, test, dev). The main differences mainly consist in configuration properties/files.
My idea was to use profiles and overlays to copy/configure the specialized output. But I'm stuck into if I have to generate multiple artifacts with specialized classifiers (ex: "my-app-1.0-prod.zip/jar", "my-app-1.0-dev.zip/jar") or should I create multiple projects, one project for every environment ?!
Should I use maven-assembly-plugin to generate multiple artifacts for every environment ?
Anyway, I'll need to generate all them at once so it seams that the profiles does not fit ... still puzzled :(
Any hints/examples/links will be more than welcomed.
As a side issue, I'm also wondering how to achieve this in a CI Hudson/Bamboo to generate and deploy these generated artifacts for all the environments, to their proper servers (ex: using SCP Hudson plugin) ?
I prefer to package configuration files separately from the application. This allows you to run the EXACT same application and supply the configuration at run time. It also allows you to generate configuration files after the fact for an environment you didn't know you would need at build time. e.g. CERT
I use the "assembly" tool to zip up each domain's config files into named files.
I would use the version element (like 1.0-SNAPSHOT, 1.0-UAT, 1.0-PROD) and thus tags/branches at the VCS level in combination with profiles (for environments specific things like machines names, user name passwords, etc), to build the various artifacts.
We implemented a m2 plugin to build the final .properties using the following approach:
The common, environment-unaware settings are read from common.properties.
The specific, environment-aware settings are read from dev.properties, test.properties or production.properties, thus overriding default values if necessary.
The final .properties files is written to disk with the Properties instance after reading the files in given order.
Such .properties file is what gets bundled depending on the target environment.
We use profiles to achieve that, but we only have the default profile - which we call "development" profile, and has configuration files on it, and we have a "release" profile, where we don't include the configuration files (so they can be properly configured when the application is installed).
I would use profiles to do it, and I would append the profile in the artifact name if you need to deploy it. I think it is somewhat similar to what Pascal had suggested, only that you will be using profiles and not versions.
PS: Another reason why we have dev/ release profiles only, is that whenever we send something for UAT or PROD, it has been released, so if there is a bug we can track down what the state of the code was when the application was released - it is easier to tag it in SVN than trying to find its state from the commit history.
I had this exact scenario last summer.
I ended up using profiles for each higher environment with classifiers. Default profile was "do no harm" development build. I had a DEV, INT, UAT, QA, and PROD profile.
I ended up defining multiple jobs within Hudson to generate the region specific artifacts.
The one thing I would have done differently was to architect the projects a bit differently so that the region specific build was outside of the modularized main project. That was it would simply pull in the lastest artifacts for each specific build rather than rebuild the entire project for each region.
In fact, when I setup the jobs, the QA and PROD jobs were always setup to build off of a tag. Clearly this is something that you would tailor to your specific workplace rules on deployment.
Try using https://github.com/khmarbaise/multienv-maven-plugin to create one main WAR and one configuration JAR for each environment.