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 working in Spring based project. My client has asked to write JUnit test cases for my service and DAO layer.
I have to take a decision regarding the Mocking framework I am going to use and same is to be conveyed to the client as soon as possible.
I have never used any Mocking framework before. I have heard of some like Mockito,JMock,EasyMock etc while googling on net. But didn't get any compelling answer for which one I should use.
So, I need some help choosing the right mocking framework.
As other comments have said, there isn't a definitively right answer for this, but I would definitely suggest going with Mockito, for a few reasons:
It provides much better error descriptions than most of the others. Verifications that fail will return exceptions explaining exactly what other calls occurred, where, and with what arguments, making debugging very simple.
It has a clear advantage over older frameworks like EasyMock: Mockito created and has very effectively implemented a far nicer model for mocking than the old record/replay/verify process that EasyMock, JMock and others follow. This is very intuitive and quite easy to get the hang of, and results in far cleaner and easier to maintain tests.
Its model has also become directly popular in many other languages (e.g. Moq), and is closer to mocking styles in dynamic languages. This makes it pretty simple to find other people familiar with it, and makes it easier for you to later use other tools.
It's rapidly becoming the standard framework used for mocking in Java projects: I work on automated testing in projects for many companies, and I've seen a substantial number of them either already using Mockito, and actively migrating to it. Searching for 'easymock mockito' comes up with many results for migrating to Mockito from EasyMock, and none in the other direction.
There's more details of the exact differences between EasyMock and Mockito at https://code.google.com/p/mockito/wiki/MockitoVSEasyMock.
More generally, I would avoid using frameworks like PowerMock unless absolutely required. PowerMock allows you to mock various elements of the codebase that normal mocking frameworks won't, but the fact you need to mock these is normally a strong indicator of some other underlying design problem. If you find yourself unable to test something without using PowerMock, you should really consider whether the structure of the code being tested could be refactored insteard (e.g. to move away from dependencies on static methods, to better use dependency injection to avoid calling constructors, etc).
I'd also suggest you also read Martin Fowler's excellent introduction to mocking. This is a little outdated now in terms of the frameworks discussed, but does still offers a really great overview to the main concepts with some nice examples.
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.
I love the concept of DI and loosely coupled system, a lot. However, I found tooling in Spring lacking at best. For example, it's hard to do "refactoring", e.g. to change a name of a bean declared in Spring. I'm new to Spring, so I would be missing something. There is no compiling time check etc.
My question is why do we want to use XML to store the configuration? IMO, the whole idea of Spring (IoC part) is to force certain creational pattern. In the world of gang-of-four patterns, design patterns are informative. Spring (and other DIs) on the other hand, provides very prescribed way how an application should be hooked up with individual components.
I have put Scala in the title as well as I'm learning it. How do you guys think to create a domain language (something like the actor library) for dependency ingestion. Writing the actual injection code in Scala itself, you get all the goodies and tooling that comes with it. Although application developers might as well bypass your framework, I would think it's relatively easy to standard, such as the main web site/app will only load components of certain pattern.
There's a good article on using Scala together with Spring and Hibernate here.
About your question: you actually can use annotations. It has some advantages. XML, in turn, is good beacause you don't need to recompile files, that contain your injection configs.
There is an ongoing debate if Scala needs DI. There are several ways to "do it yourself", but often this easy setup is sufficient:
//the class that needs injection
abstract class Foo {
val injectMe:String
def hello = println("Hello " + injectMe)
}
//The "binding module"
trait Binder {
def createFooInstance:Foo
}
object BinderImpl extends Binder {
trait FooInjector {
val injectMe = "DI!"
}
def createFooInstance:Foo = new Foo with FooInjector
}
//The client
val binder:Binder = getSomehowTheRightBinderImpl //one way would be a ServiceLoader
val foo = binder.createFooInstance
foo.hello
//--> Hello DI!
For other versions, look here for example.
I love the concept of DI and loosely
coupled system, a lot. However, I
found tooling in Spring lacking at
best. For example, it's hard to do
"refactoring", e.g. to change a name
of a bean declared in Spring. I'm new
to Spring, so I would be missing
something. There is no compiling time
check etc.
You need a smarter IDE. IntelliJ from JetBrains allows refactoring, renaming, etc. with full knowledge of your Spring configuration and your classes.
My question is why do we want to use
XML to store the configuration?
Why not? You have to put it somewhere. Now you have a choice: XML or annotations.
IMO,
the whole idea of Spring (IoC part) is
to force certain creational pattern.
In the world of gang-of-four patterns,
design patterns are informative.
ApplicationContext is nothing more than a big object factory/builder. That's a GoF pattern.
Spring (and other DIs) on the other
hand, provides very prescribed way how
an application should be hooked up
with individual components.
GoF is even more prescriptive: You have to build it into objects or externalize it into configuration. Spring externalizes it.
I have put Scala in the title as well
as I'm learning it. How do you guys
think to create a domain language
(something like the actor library) for
dependency ingestion.
You must mean "injection".
Writing the
actual injection code in Scala itself,
you get all the goodies and tooling
that comes with it.
Don't see what that will buy me over and above what Spring gives me now.
Although
application developers might as well
bypass your framework, I would think
it's relatively easy to standard, such
as the main web site/app will only
load components of certain pattern.
Sorry, I'm not buying your idea. I'd rather use Spring.
But there's no reason why you shouldn't try it and see if you can become more successful than Spring. Let us know how you do.
There are different approaches to DI in java, and not all of them are necessarily based on xml.
Spring
Spring provides a complete container implementation and integration with many services (transactions, jndi, persistence, datasources, mvc, scheduling,...) and can actually be better defined using java annotations.
Its popularity stems from the number of services that the platform integrates, other than DI (many people use it as an alternative to Java EE, which is actually following spring path starting from its 5 edition).
XML was the original choice for spring, because it was the de-facto java configuration standard when the framework came to be. Annotations is the popular choice right now.
As a personal aside, conceptually I'm not a huge fan of annotation-based DI, for me it creates a tight coupling of configuration and code, thus defeating the underlying original purpose of DI.
There are other DI implementation around that support alternative configuration declaration: AFAIK Google Guice is one of those allowing for programmatic configuration as well.
DI and Scala
There are alternative solutions for DI in scala, in addition to using the known java frameworks (which as far as I know integrate fairly well).
For me the most interesting that maintain a familiar approach to java is subcut.
It strikes a nice balance between google guice and one of the most well-known DI patterns allowed by the specific design of the scala language: the Cake Pattern. You can find many blog posts and videos about this pattern with a google search.
Another solution available in scala is using the Reader Monad, which is already an established pattern for dynamic configuration in Haskell and is explained fairly well in this video from NE Scala Symposium 2012 and in this video and related slides.
The latter choice goes with the warning that it involves a decent level of familiarity with the concept of Monads in general and in scala, and often aroused some debate around its conceptual complexity and practical usefulness. This related thread on the scala-debate ML can be quite useful to have a better grip on the subject.
i can't really comment on scala, but DI helps enforce loose coupling. It makes refactoring large apps soooo much easier. If you don't like a component, just swap it out. Need another implementation for a particular environment, easy just plug in a new component.
I agree! To me he way most people use Spring is a mild version of hell.
When you look at the standard Springified code there are interfaces everywhere, and you never really know what class is used to implement an interface. You have to look into some fantastic configuration to find that out. Easy read = not. To make this code surfable you need a very advanced IDE, like Intelly J.
How did we end up in this mess? I blame automated unit testing! If you want to connect mocks to each and every class you can not have dependencies. If it wasn't for unit testing we could probable do just as well without loose coupling, since we do not want the customer to replace single classes willy nilly in our Jars.
In Scala you can use patterns, like the "Cake Patten" to implement DI without a framework. You can also use structural typing to do this. The result is still messy compared to the original code.
Personally I think one should consider doing automated testing on modules instead of classes to escape this mess, and use DI to decouple entire modules. This strategy is by definition not unit testing. I think most of the logic lies in the actual connections between classes, so IMHO one will benefit more from module testing than unit testing.
I cannot agree that XML is problem in Java and Spring:
I use Spring and Java extensively without to much XML because most configuration is done with annotations (type and name is powerful contract) - it looks really nice. Only for 10% cases I use XML because it is easier to do it in XML than code special solution with factories / new classes / annotations. This approach was inspired by Guice and Spring from 3.0 implements its as JSR-330 (but even that I use Spring 2.5 with spring factory configured with JSR-330 annotations instead of default spring-specific #Autowired).
Probably scala can provide better syntax for developing in DI style and I'm looking at it now (pointed Cake Pattern).