Unit Testing Scala Singleton Object

Question
1 
type or paste code here

object MyObject {

  // Method that takes a String (name) as parameter and returns a greeting message
  def greet(name: String): String = {
    s"Hello, $name! Welcome to Scala!"
  }

  // Main method to test the greet method
  def main(args: Array[String]): Unit = {
    val message = greet("Alice")  // Calling the greet method
//Line1
//Line2
    println(message)  // Output: Hello, Alice! Welcome to Scala!
  }
}

consider the above code sample ,
if i want to mock this
MyObject
and change the behaviour of greet method
How can i achieve this .

Even in main method also
I have 2 lines i want to mock the behaviour of those two lines , how can i achieve that , can someone pls suggest

2

You probably can get what you want using something like mockito.
I can’t help you with the code, though, since I have never, nor plan ever, to use that kind of library or do this kind of thing.

Rather, I would refactor the code to allow proper testing without needing runtime magic.

3

I tried using the mockito and use the methods like mockstatic but that is not working , after going through the documentation i found that’s not possible .

case class FinanceData(
                                col1: String,
                                col2: String,
                                col3: String,
                                col3: String
                              )

object BankData{
  def apply()
  : Dataset[BankData] = {
    loadTable("TABLE")
      .as[FinanceData]
  }
}

I have some implemented classes that follow this convention,
can you please suggest how can i modify these things to get that achieved

4

I’ll echo @BalmungSan’s suggestion of refactoring – over the years, I’ve moved away from ever using mocks, which tend to result in terrible tests.

Instead, it’s all about the traditional guideline for good design: always separate interface from implementation.

In particular, be sparing with objects. Only put a method in an object if you are absolutely certain that you will never want a test-substitute for it. Otherwise, it’s best to define an interface that can be easily replaced in tests, and a class that implements that interface.

This, in turn, means that the singleton pattern is pretty dangerous for applications of non-trivial size. I don’t use it much, personally, for exactly this reason – I use dependency injection of one sort or another the vast majority of the time.

(Note that little of this is really all that Scala-specific. These are techniques I started evolving back in my C++ days, 25 years ago, and was refining via C# before I got to Scala.)

1 Like
5

A good general advice would be to think about the testability of your application upfront. That would mean not putting things that you may have to mock in singleton objects, but putting those things behind an interface. E.g.

trait Greeter {
  def greet(name: String): String
}

class Application(greeter: Greeter) {
  def run(): Unit = {
    val message = greeter.greet("Alice")
    ...
    println(message)
  }
}

object Main {
  def main(args: Array[String]): Unit = {
    val greeter = new GreeterImpl()
    val application = new Application(greeter)
    application.run()
  }
}

Then you can still use whatever you want for testing. Either mockito, handwritten mocks, …

1 Like
6

Those objects are simply “unmockeable”.

Depending on how you use them you have two alternatives.

  1. Assuming you only need to mock the data. Like this:
def logicToTest() = {
  // some code here.
  val ds = BankData()
  // more code here.
}

Then you can simply split that into two methods like this:

def foo() =
  logicToTest(ds = BankData())

def logicToTest(ds: Dataset[BankData]) = {
  // some code here.
  // more code here.
}

Thus, you now can pass “mock data” to logicToTest without needing to really mock anything at all.

  1. But if there is more than just the data, then you need a proper interface like this:
// Names can be adapted to better reflect your domain.
trait DataProvider[T] {
  def apply(): Dataset[T]
  // more methods
}

object BankDataProvider extends DataProvider[BankData] {
  override def apply(): Dataset[BankData] = ??
  // implement all other methods.
}

def logicToTest(bankDataProvider: DataProvider[BankData]) =
  // code here

That way you can provide a “mock implementation” for tests without issues.

7

In build.sbt :

libraryDependencies += "org.scalatest" %% "scalatest" % "3.2.18" % Test
8

Then in ./src/test/scala/…

class CubeCalculatorTest extends org.scalatest.funsuite.AnyFunSuite {
  test("CubeCalculator.cube") {
    assert(CubeCalculator.cube(3) === 28)
  }
}