We already use it for some of our js code.
Note: I did not try it but it is very similar to jsspec and jspec.
A Node.js testing toolkit. You get the same test case library, assertion library, etc. This is also great for hybrid browser and Node.js code. Write your test case with Buster.JS and run it both in Node.js and in a real browser.
Screencast: Buster.js Getting started (2:45)
* TestSwarm is also a Continuos Integration server, while you need a separate CI server for Buster.js. It does however output xUnit XML reports, so it should be easy to integrate with Hudson, Bamboo or other CI servers.
Screencast: Testacular Getting started
Overview of how JsTestDriver works at runtime:
Eclipse plugin screenshot:
Short intro video: http://www.youtube.com/watch?v=V4wYrR6t5gE
Announcement from August 25th 2010: http://www.yuiblog.com/blog/2010/08/25/introducing-yeti-the-yui-easy-testing-interface/
If you have experience with this test-runner, please contribute with more info :)
Project home: http://yuilibrary.com/projects/yeti/
This is a test-runner that might interest developers familiar with Ruby or Ruby on Rails. The syntax is based on RSpec that's used for testing in Rails projects.
If you have experience with this test-runner, please contribute with more info :)
Project home: https://github.com/pivotal/jasmine/
QUnit shares some history with TestSwarm (above):
QUnit was originally developed by John Resig as part of jQuery. In 2008 it got its own home, name and API documentation, allowing others to use it for their unit testing as well. At the time it still dependended on jQuery. A rewrite in 2009 fixed that, now QUnit runs completelty standalone. QUnit's assertion methods follow the CommonJS Unit Testing specification, which was to some degree influenced by QUnit.
Project home: http://qunitjs.com/
How do I use JUnit to test a class that has internal private methods? It seems bad to change the access modifier for a method just to be able to run a test.
If you have somewhat of a legacy application, and you're not allowed to change the visibility of your methods, the best way to test private methods is to use reflection.
Internally we're using helpers to get/set
private static variables as well as invoke
private static methods. The following patterns will let you do pretty much anything related to the private methods and fields. Of course you can't change
private static final variables through reflection.
Method method = targetClass.getDeclaredMethod(methodName, argClasses); method.setAccessible(true); return method.invoke(targetObject, argObjects);
And for fields:
Field field = targetClass.getDeclaredField(fieldName); field.setAccessible(true); field.set(object, value);
targetClass.getDeclaredMethod(methodName, argClasses) lets you look into
private methods. The same thing applies for
setAccessible(true) is required to play around with privates.
I'd like to unit test my Android application but I found that test driven development in Android is far from trivial at the moment.
Any tips, tricks, war stories for building light weight and preferably fast running tests?
You should try Robotium! Go to Robotium.org and download the example test project. Robotium is a really easy to use framework that makes testing of android applications easy and fast. I created it to make testing of advanced android applications possible with minimum effort. Its used in conjunction with ActivityInstrumentationTestCase2.
I want to start using mock objects on my next C# project.
After a quick Google search I've found there are many:
So my question is: what one is your favourite .NET mocking framework and why?
I've not used most of the ones you've listed, so I can't be objective about it, but I use Moq and it has been awesome. The fluent interface makes it a joy to work with. For example:
mockService.Setup(s => s.GetCustomers()).Returns(new List<Customer>());
@Ngu Soon Hui, I wasn't aware that the other frameworks don't have compile-time checking. Moq certainly does. In my example above, if the service class that mockService is mocking doesn't have a GetCustomers() method, I would get a compile-time error. I'd also get one if the GetCustomers() method didn't return a List<Customer> or an interface like IList<Customer>.
I am working to integrate
unit testing into the development process on the team I work on and there are some skeptics. What are some good ways to convince the skeptical developers on the team of the value of Unit Testing? In my specific case we would be adding
Unit Tests as we add functionality or fixed bugs. Unfortunately our code base does not lend itself to easy testing.
Every day in our office there is an exchange which goes something like this:
"Man, I just love unit tests, I've just been able to make a bunch of changes to the way something works, and then was able to confirm I hadn't broken anything by running the test over it again..."
The details change daily, but the sentiment doesn't. Unit tests and test-driven development (TDD) have so many hidden and personal benefits as well as the obvious ones that you just can't really explain to somebody until they're doing it themselves.
But, ignoring that, here's my attempt!
Unit Tests allow you to make big changes to code quickly. You know it works now because you've run the tests, when you make the changes you need to make, you need to get the tests working again. This saves hours.
TDD helps you to realise when to stop coding. Your tests give you confidence that you've done enough for now and can stop tweaking and move on to the next thing.
The tests and the code work together to achieve better code. Your code could be bad / buggy. Your TEST could be bad / buggy. In TDD you are banking on the chances of BOTH being bad / buggy being low. Often it's the test that needs fixing but that's still a good outcome.
TDD helps with coding constipation. When faced with a large and daunting piece of work ahead writing the tests will get you moving quickly.
Unit Tests help you really understand the design of the code you are working on. Instead of writing code to do something, you are starting by outlining all the conditions you are subjecting the code to and what outputs you'd expect from that.
Unit Tests give you instant visual feedback, we all like the feeling of all those green lights when we've done. It's very satisfying. It's also much easier to pick up where you left off after an interruption because you can see where you got to - that next red light that needs fixing.
Contrary to popular belief unit testing does not mean writing twice as much code, or coding slower. It's faster and more robust than coding without tests once you've got the hang of it. Test code itself is usually relatively trivial and doesn't add a big overhead to what you're doing. This is one you'll only believe when you're doing it :)
I think it was Fowler who said: "Imperfect tests, run frequently, are much better than perfect tests that are never written at all". I interprate this as giving me permission to write tests where I think they'll be most useful even if the rest of my code coverage is woefully incomplete.
Good unit tests can help document and define what something is supposed to do
Unit tests help with code re-use. Migrate both your code AND your tests to your new project. Tweak the code till the tests run again.
This presentation is an excellent introduction to the subject. (this version requires Firefox)
A lot of work I'm involved with doesn't Unit Test well (web application user interactions etc.), but even so we're all test infected in this shop, and happiest when we've got our tests tied down. I can't recommend the approach highly enough.
I was testing my app on the simulator when it crashed on clicking a button of a UIAlertView. I stopped debugging there, made some changes to the code and built the app again. Now when I run the application, I get this error in the console
Couldn't register com.myApp.debug with the bootstrap server. Error: unknown error code. This generally means that another instance of this process was already running or is hung in the debugger.Program received signal: “SIGABRT”.
I tried removing the app from the simulator, doing a clean build but I still get this error when I try to run the app.
What should I do to be able to run the app on my simulator again?
Try quitting and restarting the simulator? If "worse comes to worst" you can always try restarting: in my experience this should fix it.
I worked on an embedded system this summer written in straight C. It was an existing project that the company I work for had taken over. I have become quite accustomed to writing unit tests in Java using JUnit but was at a loss as to the best way to write unit tests for existing code (which needed refactoring) as well as new code added to the system.
Are there any projects out there that make unit testing plain C code as easy as unit testing Java code with JUnit? Any insight that would apply specifically to embedded development (cross-compiling to arm-linux platform) would be greatly appreciated.
What frameworks exist to unit test Objective-C code? I would like a framework that integrates nicely with Xcode.
Xcode includes OCUnit, an Objective-C unit testing framework, and support for running unit tests (OCUnit or otherwise) as part of your project's build process. Xcode's unit testing support is described in the Xcode Unit Testing Guide.
I've written a series of weblog posts about how to perform some common tasks with Xcode unit testing:
Finally, I've written a few posts on how to write tests for Cocoa user interfaces; the way Cocoa is structured makes it relatively straightforward, because you don't have to spin an event loop or anything like that in most cases.
This makes it possible to do test-driven development for not just your model-level code but also your controller-level and even view-level code.
Hot-on-the-heels of of my previous unit testing related question, here's another toughie:
I have thus far avoided the nightmare that is testing multi-threaded code since it just seems like too much of a minefield. I'd like to ask how people have gone about testing code that relies on threads for successful execution, or just how people have gone about testing those kinds of issues that only show up when two threads interact in a given manner?
This seems like a really key problem for programmers today, it would be useful to pool our knowledge on this one imho.
Look, there's no easy way to do this. I'm working on a project that is inherently multithreaded. Events come in from the operating system and I have to process them concurrently.
The simplest way to deal with testing complex, multithhreaded application code is this: If its too complex to test, you're doing it wrong. If you have a single instance that has multiple threads acting upon it, and you can't test situations where these threads step all over each other, then your design needs to be redone. Its both as simple and as complex as this.
There are many ways to program for multithreading that avoids threads running through instances at the same time. The simplest is to make all your objects immutable. Of course, that's not usually possible. So you have to identify those places in your design where threads interract with the same instance and reduce the number of those places. By doing this, you isolate a few classes where multithreading actually occurs, reducing the overall complexity of testing your system.
But you have to realize that even by doing this you still can't test every situation where two threads step on each other. To do that, you'd have to run two threads concurrently in the same test, then control exactly what lines they are executing at any given moment. The best you can do is simulate this situation. But this might require you to code specifically for testing, and that's at best a half step towards a true solution.
Probably the best way to test code for threading issues is through static analysis of the code. If your threaded code doesn't follow a finite set of thread safe patterns, then you might have a problem. I believe Code Analysis in VS does contain some knowledge of threading, but probably not much.
Look, as things stand currently (and probably will stand for a good time to come), the best way to test multithreaded apps is to reduce the complexity of threaded code as much as possible. Minimize areas where threads interact, test as best as possible, and use code analysis to identify danger areas.
What's the best framework for creating mock objects in Java? Why? What are the pros and cons of each framework?
I've had good success using Mockito.
When I tried learning about JMock and EasyMock, I found the learning curve to be a bit steep (though maybe that's just me).
I like Mockito because of its simple and clean syntax that I was able to grasp pretty quickly. The minimal syntax is designed to support the common cases very well, although the few times I needed to do something more complicated I found what I wanted was supported and easy to grasp.
Here's an (abridged) example from the Mockito homepage:
import static org.mockito.Mockito.*; List mockedList = mock(List.class); mockedList.clear(); verify(mockedList).clear();
It doesn't get much simpler than that.
The only major downside I can think of is that it won't mock static methods.