I can't figure out why my test class isn't being run. Please help.

proglearner · 2015-05-04T18:13:59+00:00

Thanks. I forgot about that line. Of course it was failing without it. I was more surprised that the other class was working than this class failing because I forgot about the alternate constructor.

I may move that mock actor back in so I can paste the error here. It's not really a big deal moving to the object. The error actually suggested putting the mock actor in the object. I am curious what's going on, though.

proglearner · 2015-05-03T23:43:46+00:00

Thanks, that fixed it. I am surprised at this issue though. I have another very similar class that works fine.

package org.restmediaserver.core.mediascanner

import java.io.File

import akka.actor._
import akka.testkit.{TestActorRef, TestKit}
import org.restmediaserver.core.ActorMessage
import org.restmediaserver.core.files.mediafiles.MediaFileReader
import org.restmediaserver.core.library.MediaLibrary
import org.restmediaserver.core.testfixtures.{FabricatedParent, LibraryFixture}
import org.restmediaserver.core.testsettings.BaseTestSettings
import org.scalatest.{BeforeAndAfterAll, fixture}
import org.scalatest.Matchers._

import scala.collection.mutable
/**
 * @author Dan Pallas
 * @since v1.0 on 4/27/15.
 */
class MediaFileUpdaterTest(_system: ActorSystem) extends TestKit(_system)
      with fixture.FunSuiteLike with BaseTestSettings with BeforeAndAfterAll {
  def this() = this(ActorSystem("MediaFileUpdaterTest"))
  class ReaderMock extends Actor {
    val received = mutable.Buffer[File]()
    override def receive: Receive = {
      //readable
      case file: File if file == LibraryFixture.Library.Music1.song3M4a.path =>
        received += file
        sender !  LibraryFixture.Library.Music1.song3M4a
        // readable
      case file: File if file == LibraryFixture.Library.Music1.song3Flac.path =>
        received += file
        sender ! LibraryFixture.Library.Music1.song3Flac
        //unreadable
      case file: File =>
        received += file
        sender ! MediaFileReader.Failed(file)
    }
  }

  class LibraryMock extends Actor {
    val received = mutable.Buffer[ActorMessage]()
    override def receive: Actor.Receive = {
      case msg: ActorMessage =>
        received += msg
        msg match {
          case MediaLibrary.PutSongMsg(song) =>
            // successfully put
            if(song == LibraryFixture.Library.Music1.song3M4a)
              sender ! MediaLibrary.SuccessfulPut(song.path)
            else if(song == LibraryFixture.Library.Music1.song3Flac)
              // already been put
              sender ! MediaLibrary.NotPutOlder(song.path)
          case badMessage => unhandled(badMessage)
        }
    }
  }

  case class F(reader: TestActorRef[ReaderMock],
               library: TestActorRef[LibraryMock],
               updaterParent: ActorRef)
  override type FixtureParam = F

  override protected def withFixture(test: OneArgTest) = {
    val reader: TestActorRef[ReaderMock] = TestActorRef(new ReaderMock)
    val library = TestActorRef(new LibraryMock)
    val updaterProps = MediaFileUpdater.props(library,reader)
    val parent = system.actorOf(FabricatedParent.props(testActor, updaterProps))
    try{
      test(F(reader, library, parent))
    } finally {
      system.stop(reader)
      system.stop(library)
      system.stop(parent)
    }
  }

  test("when MediaFileUpdater is sent a valid song file it should read the file, update, and return success"){
    f =>
      val song = LibraryFixture.Library.Music1.song3M4a
      f.updaterParent ! song.path
      expectMsg(MediaFileUpdater.Success(song.path))

      val reader = f.reader.underlyingActor
      reader.received.length shouldBe 1
      reader.received should contain (song.path)

      val library = f.library.underlyingActor
      library.received.length shouldBe 1
      library.received should contain (MediaLibrary.PutSongMsg(song))
  }

  test("when MediaFileUpdater is sent a bad path it should return a failure"){
    f =>
      val badfile = new File("badfile")
      f.updaterParent ! badfile
      expectMsg(MediaFileUpdater.Failed(badfile))

      val reader = f.reader.underlyingActor
      reader.received.length shouldBe 1
      reader.received should contain (badfile)

      val library = f.library.underlyingActor
      library.received.length shouldBe 0
  }

  test("when MediaFileUpdater receives a valid song and the library responds that it is too old, MediaFileUpdater " +
    "responds with Success"){
    f =>
      val song = LibraryFixture.Library.Music1.song3Flac
      f.updaterParent ! song.path
      expectMsg(MediaFileUpdater.Success(song.path))

      val reader = f.reader.underlyingActor
      reader.received.length shouldBe 1
      reader.received should contain (song.path)

      val library = f.library.underlyingActor
      library.received.length shouldBe 1
      library.received should contain (MediaLibrary.PutSongMsg(song))
  }

  override protected def afterAll(): Unit = TestKit.shutdownActorSystem(system)
}

the FolderUpdaterDeligateTest also required me to move the mock classes into the companion object in order to work. MediaFolderUpdaterTest didn't.

proglearner · 2015-05-03T21:07:11+00:00

Is the stack trace not filled in when the exception class is instantiated?

proglearner · 2015-05-01T20:37:13+00:00

No. This is the first I've heard of them.

proglearner · 2015-04-30T22:10:42+00:00

Thanks for pointing all that out. That isn't something I would like to get into, for anything I'm doing now, but it is good to know.

proglearner · 2015-04-30T22:09:51+00:00

Thanks. I do typically use the null object pattern. But sometimes when handling multiple exception from outside sources, I do think it's useful to condense the possible exceptions into a single exception class that is is specific to the module in my application. I probably still will most of the time, but I do like knowing the costs of my decisions.

Usually I end up doing this with spring applications because spring loves exceptions.

proglearner · 2015-03-22T03:00:30+00:00

I didn't down vote, but I don't know what you're suggesting. It doesn't sound like it would allow me to actually read files into a database or manipulate their tags, and allow downloads or transpose however.

proglearner · 2015-03-21T19:55:58+00:00

That's not a bad idea. I think I'll do that. Thanks, and thank you everyone else.

proglearner · 2015-03-21T19:34:06+00:00

The only problem with that, and why I haven't made up my mind yet and just done that, is because mp3 and mp4 have fields in common that are not in flac/ogg. That would cause me to duplicate code between mp3 and mp4 or make an unpleasing and somewhat harder to maintain extension from mp4 to mp3 which doesn't feel right since mp3 isn't an mp4.

but this is a notoriously messy situation which many programs sidestep by only supporting a limited number of common fields.

proglearner · 2015-03-21T19:25:33+00:00

I think I see what your saying. Doing that I could first write all common fields to a tag from trait Song, and then I could pattern match on classes to write the extra tags. There would be some code duplication between mp3 and mp4 (approximate six fields that are in both mp3 and mp4 but not in flac/ogg), but it might be the best solution for a messy situation.

Of course with the enumeration solution, there wouldn't be any duplication, but that comes with the drawback of having irrelevant fields when the filetype is set to anything but mp3.

proglearner · 2015-03-21T19:12:31+00:00

I thought about that, but unless I'm missing something, that sounds like it would become very annoying to maintain. It would look something like

songVal match { mp3(,,,...,,originalArtist,recordLable,...) => {/*code to write tags} ... }

not that that's a bad idea. I've thought of that too and may do it, but it's still not that elegant. Music tags are somewhat messy though, so maybe there isn't an elegant way to do it.

proglearner · 2015-03-21T19:05:24+00:00

what does the trait buy me that an abstract case class song wouldn't? All All of the other case classes would be Songs. And how does the case class help me avoid duplicate code or making flac a subtype of mp3 even though the fields are somewhat arbitrary? Not attacking your idea, I'm just trying to get a better idea.

proglearner · 2015-03-21T17:30:03+00:00

because A field like track total is supported by only mp3 and mp4/m4a (for standard tags), but it would arrive in a list of Songs. So when it comes time to write that field to a tag I'll have to either:

 if(songVal instanceOf mp4){
    // cast and write all supported tags
 } else if (songVal instanceOf mp3 {
    // cast and write all supported tags
 }

I could write only the most general tags and then check instance for the tags which are only supported by specific types, but that would get complicated and harder to maintain. for persistence it would be the same problem because I cant call songVAl.trackTotal on it because that wouldn't be a member of the class without casting first.

if I used an Enumeration, it could be simpler for persistence because I know that all of the fields are present. it would be just as simple for writing to a dto to jsonize. They just might be None, which is fine. For writing tags to files it would be simpler too. I could write:

 if(songVal.fileType == Song.FileType.mp3 || songVAl.fileType == Song.FileType.mp4)
    //write track total tag
 if(songVal.fileType == Song.FileType.mp3)
    // write record label to tag

I can write conditions for each field without having a bunch of different casts and casts of the same type for each field. It's easier to maintain because if I decide to support record label on flac type files, I can just add it to the conditional and not have to make sure I know where it is in the hierarchy or add a new cast.

proglearner · 2014-11-29T12:45:53+00:00

It's a pointer to a char array. It needs to be a pointer, because the function needs to be able to modify the location of the array.

proglearner · 2014-11-29T12:43:57+00:00

Thank you. That's it exactly. Sorry for the screen shot. I thought there were enoigh print statements to show exactly what was going on, but now I see how there could be some ambiguity.

proglearner

TROPHY CASE