I have implemented unit tests for my MVC Application using the NUnit Framework.
The Unit testing project contains multiple [TestFixture] classes that need to be tested. I'm using a TestFixture for each Module in my MVC project, but all of the modules are inside in single Namespace.
I would like to be able to test a single Module through its [TestFixture] using the Unit Tool in FinalBuilder (automation) or Manually, instead of testing the whole unit test project.
My total test case count is around 2000, made up of 20 modules each with about 100 test cases. Any changes made to one of modules or it's TestFixture will mean that only that modules tests need to be run. This will minimise the amount of time that needs to be taken to wait for unrelated tests to complete.
As far as manual testing goes, in the Nunit gui, you can simply select a test fixture and run it to. I haven't used finalbuilder, but assuming it's similar to the nunit-console application, you have a couple of options.
You can pass arguments to specify particular test cases, for example:
nunit-console some.dll /run=SomeTestFixture
Or, you can mark up your test fixtures with categories and then tell the test runner to only include tests in those categories, so in your code:
[TestFixture]
[Category("SomeTestCategory")]
public class SomeTestClass {
Then in your nunit call:
nunit-console some.dll /include=SomeTestCategory
That said, assuming that your tests are actually unit tests, 2000 doesn't seem like that many and they shouldn't really be taking all that long to run...
Related
I would like to develop several test suites with Google Test framework.
All these test suites should share same test fixture.
I would like to have une .cpp file per test suite. One of the cpp file, contains the fixture and the test suite number 1.
Could you hint at the right architecture to do so?
I create une Test Suite per cpp file, with one Fixture per Test Suite. The code duplication is minimal.
A test fixture is aimed at having common code for several tests which operate on same data, with same context... One fixture per test suite seems relevant, if one test suite is characterized by a given context.
If you find yourself writing two or more tests that operate on similar
data, you can use a test fixture. It allows you to reuse the same
configuration of objects for several different tests.
We have a large Hybris project here and to run all the tests with takes much too long (hours, yes, a large consulting company created that crap). My target is to reduce all the spring based integration tests and replace them by real unit tests.
But when running the tests with the Hybris ant build for one extension (ant alltests -Dtestclasses.extensions=myext) starts a server with the junit tenant also if there are only non Spring based unit tests in that extension. I also tried to use ant unittests but that one does not even executes my tests.
Is there any way to run only the tests annotated with #UnitTest without any server start in an ant run?
PS: I have a hybris 5.1 and 5.3 commerce suite
You should use ant unittests and not ant unit tests:
ant unittests -Dtestclasses.extensions=myext
Note
Running simple unit tests exclusively is not so easy whenever someone uses somewhere Registry.getApplicationContext() in the code under test!
In fact, Registry.getApplicationContext() starts a Hybris instance. If that happens to you, you need to eliminate that particular call to Registry.getApplicationContext() with a better class design and/or mocks.
This is good information. However, in my opinion, even running the unit tests for a single extension is still too much. Unit tests are supposed to be FAST! I should be able to run a single unit test method from within my IDE if I choose to. The whole concept of "red-green testing" is lost if I have to wait for a bunch of non-relevant unit tests to run every time I want to test my refactored code.
Because these tests rely on a runtime environment, there are NO unit tests in Hybris. There are only integration tests because they all rely on a running Hybris system to be executed.
I would like to give some details how to run unittests from within the IDE.
Install IntelliJ
Install Hybris plugun (https://plugins.jetbrains.com/plugin/7525-hybris-integration)
Import the project
Run the UnitTest as any normal developer will do it
Enjoy :)
I have a problem with executing tests in JUnit. Imagine you have one test case class with f.e. 100 tests, no test suite and no main program - test case class test the device on com port. JUnit project is in Netbeans. I want to run tests - but not all of them at the same time, i would like to choose tests to run before actual testing.
Once I saw something like that in eclipse - but it wasn't my project and I don't know how it was done and how to do the same thing in netbeans. It was a separate window, poping up before running tests. In this window there were checkboxes with names of methods with #Test annotation and you could choose tests you wanted to run and click run - so it let you to run what you wanted.
Does anyone know how to do it in netbeans? Is it any library or plugin?
Any help will be appreciated.
You can take a look at Run single test from a JUnit class using command-line. It does allow you to specify what test you want to run given a class with multiple test cases in it. Being command-line you can then script your own test suite that runs the specific ones you want.
I also noticed your other question Junit: changing sequence of test running. With the scripting approach you can actually control the order of your testing.
This approach does not take advantage of Eclipse's or NetBean's JUnit test runners though, so it is a very specific workaround.
Netbeans nowadays support running single tests:
I have a lot of test suits and tests and the execution time of those tests are so long.
I have an idea of about adaptive testing to modify a TestUnit framework (JUnit for example) to run those tests which takes less time at the beginning and those which are taking a long time at the end.
Also, I'm thinking of defining an annotation like "#RunFirst" to declare and notify the test unit framework to run that test at the beginning so the developer can test the functionality that is working on at the beginning which saves a lot of time to get the answer.
My question are
Is there any programmatic way that we order the execution of tests? (I already checked this page but it doesn't look like an appealing solution to me)
can we access to the statistics of each test ? like how long does each one takes?
Can we get the result of each test after each test is executed and show it to the user? or we have to wait until all the tests are executed?
to run those tests which takes less time at the beginning
If you are really interested in doing this, you have some test-cases that take a long time. Those are almost certainly not really unit tests, but rather integration tests. I would instead suggest moving those test-cases to a separate "integration tests" directory. Run all the integration tests after the unit tests.
Edit
See the following related questions:
How-to organize integration tests and unit tests
Maven - separate integration tests from unit tests
Do you separate your unit tests from your integration tests?
I am new to testing in general and am working on a Grails application.
I want to write a test that says "when this action is called, the correct view is returned". I don't know how to go about deciding if I should make something like this a unit test or an integration test. Either test would show me what I want - how do I decide?
One problem with integration tests is their speed. For me, integration tests take 15+ seconds to start up. In that time, certain things do slip out of mind focus.
I prefer to go with unit tests that start in no more then 2 sec and can be run several times in those 15 seconds. Especially with mockDomain(). Especially with Grails 2.0 implementing criteria and named queries in unit tests.
One more argument for unit tests is they force you to decouple your code. Integration tests always tempt you to just rely on some other component existing and initialized.
From Grails Docs section 9.1
Unit testing are tests at the "unit" level. In other words you are
testing individual methods or blocks of code without considering for
surrounding infrastructure. In Grails you need to be particularity
aware of the difference between unit and integration tests because in
unit tests Grails does not inject any of the dynamic methods present
during integration tests and at runtime.
From Grails Docs section 9.2
Integration tests differ from unit tests in that you have full access
to the Grails environment within the test. Grails will use an
in-memory HSQLDB database for integration tests and clear out all the
data from the database in between each test.
What this means is that a unit test is completely isolated from the Grails environment whereas an integration test is not. According to Scott Davis, author of this article, it is acceptable to write only integration tests...
Unit vs. integration tests
As I mentioned earlier, Grails supports two basic types of tests: unit
and integration. There's no syntactical difference between the two —
both are written as a GroovyTestCase using the same assertions. The
difference is the semantics. A unit test is meant to test the class in
isolation, whereas the integration test allows you to test the class
in a full, running environment.
Quite frankly, if you want to write all of your Grails tests as
integration tests, that's just fine with me. All of the Grails
create-* commands generate corresponding integration tests, so most
folks simply use what is already there. As you'll see in just a
moment, most of the things you want to test require the full
environment to be up and running anyway, so integration tests are a
pretty good default. If you have noncore Grails classes that you'd
like to test, unit tests are perfectly fine.
First go through this chapter of the grails guide http://grails.org/doc/latest/guide/9.%20Testing.html
It talks about testing controllers and ability to get controller response like so :
controller.response.contentAsString
Now deciding on which test is more of an art rather than science. I prefer unit tests cause they are faster to run :)
Its a really interesting and challenging question to answer, but the truth is it really depends on what exactly you are testing.
Take the following test: "saving a book to the database". The hints are in the description. We are saying we need a book and we need a database, so in this case a unit test wont do because we need the integrated database.
My advice is write the full test description down and break it down like I did above. It will give you the hints to help you decide.
This is made easier with spock where you can use strings for test names.