JUnit Testing Scala in Eclipse

Being a fairly new convert to agile development methods, including test driven development, I knew the first thing I would want to get up and running with Scala was a unit testing framework. The NetBeans plugin has built-in JUnit support which served me very well. But I also wanted to get some unit testing working with the Eclipse plugin. It took me a while to get JUnit testing setup with Eclipse, mainly due to my lack of experience in the Java ecosystem. To help future explorers down this path, here are a few lessons I learned.

Put the your tests in a separate source folder. See this tutorial on setting up JUnit in Eclipse for more information.

Add JUnit to your project's build path. Select the project and choose "Build Path" -> "Add Libraries...". Then choose the JUnit jar.

Add the output directory of your project to your build path. See this short guide from the makers of Spec.

To get you started, here is a simple test:

package tests

import junit.framework._
import org.junit.Assert._

class FirstTest extends TestCase {
 override def setUp() = {
 }

 override def tearDown() = {
 }

 def testOne() = {
   assertEquals(1, 1)
 }
}

Test Driven Development Best Practices for C#

As I have mentioned before, my company has recently started to use the Test Driven Development style of programming. In order to help us write testable code, I came up with this simple list of best practices for making our C# code base more testable. (Some of the links refer to limitations of Rhino Mocks, a mocking framework for C#, but the rules apply more generally as well.)

To maximize the testability of code, follow these rules:

1. Write the test first, then the code. (PRIME DIRECTIVE!)
   Reason: This ensures that you write testable code and that every line of code gets tests written for it.
   
   
2. Design classes using dependency injection.
   
   See: Intro to Rhino Mocks (see "Creating Testable Web Applications" section) and Dependency Injection Article
   Reason: You cannot mock or test what cannot be seen.


3. Separate UI code from its behavior using Model-View-Controller or Model-View-Presenter.
   
   Reason: Allows the business logic to be tested while the parts that can't be tested (the UI) is minimized.
   
   
4. Do not write static methods or classes.
   
   See: Intro to Rhino Mocks (see "Creating Testable Web Applications" section) and Rhino Mocks Limitations
   Reason: Static methods are difficult or impossible to isolate and Rhino Mocks is unable to mock them.
   
   
5. Program off interfaces, not classes.
   
   Reason: Interfaces can be easily mocked using Rhino Mocks and other mocking frameworks.
   
   
6. Isolate external dependencies.
   Reason: Unresolved external dependencies.
   
   
7. Mark as virtual the methods you intend to mock.
   See: Rhino Mocks Limitations
   Reason: Rhino Mocks is unable to mock non-virtual methods.

Test Driven Development

We have started using Test Driven Development at work, which is an entirely new way to program. This goes along with our existing use of Agile Development, so we are totally embracing the latest and (hopefully) greatest in programming philosophy.