Do you think it is advisable to use Code Contracts inside your unit tests?
I don't think it is since it is like creating unit tests to test your unit tests.
Therefore I would not activate the Code Contracts Static Checking nor the Runtime Checking for a Unit Test project.
To clarify, I would like to know, in particular, if you would write Code Contracts code inside your unit tests.
I think it's a good idea to enable Code Contracts for unit tests, then any contract failures can be caught when the tests are run.
However it's usually not useful to do any contract checking in the test methods themselves, except in helper methods used by the test methods.
Improved testability
•each contract acts as an oracle, giving a test run a pass/fail indication.
•automatic testing tools, such as Pex, can take advantage of contracts to generate more meaningful unit tests by filtering out meaningless test arguments that don't satisfy the pre-conditions.
Related
I'm new to integration tests, and currently doing it with SpringBootTest.
Roughly what I'm gathering from examples is that each method would be one integration test (corresponds to one REST call).
But what if I want to test a scenario where it's a sequence of steps? Like Create User->Update User->Delete User.
Maybe that's not called an integration test? And if so, how do I chain these inside SpringBootTest?
Well, it is okay to have a testing order at that level of testing, what I mean with level is this:
Unit Testing -> Component Testing -> Integration Testing -> end to end testing.
As you move to the right, the tests are more complex to set up and execute.
In my opinion, the tests you describe are Integration Test, so, having order is fine, but, you should try to avoid adding complexity, for instance, using a mock in-memory database like H2, and populate it when you are testing, helps a lot.
As the database is in memory, you won't need to take care of cleaning or restoring the state of that database, the data just will be gone after the testing finishes.
Now, you need to take care of the order of the test methods. JUnit5 uses a new annotation #TestMethodOrder and JUnit4 uses #FixMethodOrder that is not pretty customizable, you can find more information here
And finally, I suggest using something more BDD related like Cucumber for that kind of tests
The title says it all.
I'm working on writing a test that combines two other tests. Instead of repeating code, is there a way to call an rspec test from inside another rspec test, or do I have to write the new test long hand?
RSpec is a unit test framework and unit tests are intended to exclusively test the internal functionality of a single component. Dummy values and mocks should be injected through some form of mock-ups for tests that use external components.
Your code and tess probably aren't following the Single Responsibility Principle, nor standards of test-driven development if you have to do this strange implementation to have run RSpec tests. I'd suggest reading Clean Code by Robert Martin or some other book on programming theory, or just wikipedia Test Driven Development and RSpec guidelines.
If you are doing integration testing which is totally necessary, then you should try some other test strategies too.
I am currently writing unit tests for some of my methods and I still have a lot to write.
Is there a way to mark methods in my primary project as covered or handled by unit tests?
I would like to have some overview.
I've been learning TDD/BDD using MiniTest. What I'm trying to figure out is what parts of my code should be tested with MiniTest::Unit::TestCase and which parts should be tested using MiniTest::Spec.
I understand the difference between unit testing and integration testing, what I can't seem to grasp from examples across the web is whether or not a TestCase and a Spec are both unit tests or if a TestCase is used for a unit test and a Spec used for integration testing?
Should I keep my quick unit tests in MiniTest::Unit::TestCase classes and longer integration testing, which more often describe features, in MiniTest::Spec expectations? Does it even matter, or is it a question of personal preference?
Whether I use MiniTest::Unit (with assertions) vs. MiniTest::Spec, is determined by who I am writing them for.
For code I write myself, without any "customer" requirements, I'd use MiniTest::Unit. The tests make sense to me and reading them is terse and to the point.
If I'm writing code for a customer who has a list of requirements, I'd use MiniTest::Spec. The spec files are more readable to a non-programmer.
Note: MiniTest underwent an overhaul last year so some of the module names changed but the idea is the same, MiniTest supports a more terse, or more verbose, way of writing unit tests.
I have some tests which are dependent on the success and failure of some tests. How can I define dependency as I am using VS2010 Mstest and selenium.
E.g
if test1 is failed then dont run test5, test 6. is this possible.
Unit Tests should always be isolated and completly non dependent on and thing else to run, not make non-fragile.
You could setup catagories with MSTest to seperate them into deferent logical structures.
A great book to find more details is this http://artofunittesting.com
Roy has also does alot of public speaking which is recorded online
Cheers
Tests shouldn't have dependencies between them.
If you have dependencies, then running them in a different order, or in isolation will cause them to fail sporadically - this can be very confusing for anyone else that is running the tests.
It's much better to define tests that setup their own data and assert something specific. You can use a mocking framework like Rhino Mocks to reduce the dependencies between modules of code by faking (mocking) areas that aren't relevant to your test. This is made much easier if you also use a dependency injection framework like Microsoft Unity as your code will have many more seams where mocking can be applied.