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.
Related
As I mentioned in the title, I'm interested in how TDD is done in Spring. I am quite new to the notion of unit testing. I've read some articles about TDD. It is said that in TDD, first the tests are written based on requirements, they fail, then with the correct implementation, they succeed. But what should be tested in Spring? The main question is how they should be tested. I have no clue about how I should start, how to evaluate that what should be tested. I am searching for correct methods or conventions to write test-driven code if there's any.
Thanks in advance
TDD is not dependent on the framework you are using. TDD is about the mindset and designing your code based on the failing requirement that's why we write down tests first.
https://medium.com/#mithunsasidharan/test-driven-development-an-overview-46ebc817d580
The framework like Spring makes it easier to write down test cases using principles like Dependency Inversion. And they also provide all unit testing libraries dependencies.
You can check Mockito, Junit to go ahead with testing your code.
https://site.mockito.org/
I will avoid testing the framework functionalities, I would be more interested to test my business logic in it and TDD helps me deigning in a better way.
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.
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.
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.