Easy to way test your solutions?

[teem...@gmail.com]

I'm doing the exercises in the book, and while some of them have built-in functions to test them, like testFib, some don't, like isSorted. I'd like to be able to just load my solution to a REPL and test them out with different numbers. Is there an easy way to do this with SBT? Right now I'm using 'console' and :load with the whole path, but this seems kind of clunky. Is there a way to have some exercises automatically in scope or something similar? Or is there an even better way to test your solutions?

[Brian T. Grant]

I'm using test-driving my solutions using ScalaTest. If you're interested in exploring this option, I can provide some direction for getting the project set up with ScalaTest and running tests from SBT.

[teem...@gmail.com]

maanantai 19. kesäkuuta 2017 4.57.03 UTC+3 Brian T. Grant kirjoitti:
> I'm using test-driving my solutions using ScalaTest. If you're interested in exploring this option, I can provide some direction for getting the project set up with ScalaTest and running tests from SBT.
>
> On Tuesday, June 6, 2017 at 3:32:06 AM UTC-5, teem...@gmail.com wrote:I'm doing the exercises in the book, and while some of them have built-in functions to test them, like testFib, some don't, like isSorted. I'd like to be able to just load my solution to a REPL and test them out with different numbers. Is there an easy way to do this with SBT? Right now I'm using 'console' and :load with the whole path, but this seems kind of clunky. Is there a way to have some exercises automatically in scope or something similar? Or is there an even better way to test your solutions?

Thanks, but I ended up finding a way (just a couple of days ago) to try things out a bit quicker: by writing ~console in sbt, when you save your code the console recompiles automatically. Also, it's possible to import the custom List class for example by import fpinscala.datastructures._. This was roughly what I was looking for.

[Brian T. Grant]

That's great! I'm familiar with the use of ~ in the SBT console, but I've never used ~console before; I'll have to check that one out. I typically use ~testOnly or ~testQuick with my SBT-based projects.

[teem...@gmail.com]

I'd be interested in testing it more thoroughly as well. Do you have an example of how you do it?

[Brian T. Grant]

Sure thing. Here's the Bitbucket project I'm working off of as I go through the book. 

Probably the hardest part to figure out is how to add the ScalaTest dependency to the project if you're not familiar with SBT. Find the following change in build.sbt:  

.settings(libraryDependencies += "org.scalatest" %% "scalatest" % "3.0.1" % "test")

Once ScalaTest has been added as a dependency, you can write tests in any of the supported styles. I have typically used FunSuite or WordSpec in my tests. You can browse the /exercises/src/test/scala/fpinscala branch of the project to see some of the tests I have written.

While I'm developing, I typically run ~testQuick from the SBT shell. This will ensure that, on each file save, code is compiled and only the tests that would be impacted by the change will be run.

That should get you most if not all of the way to being able to adopt a TDD approach to the book's exercises. Please reply if any of the instructions above either don't make sense or if you have any additional questions. 

Brian

[teem...@gmail.com]

Thanks, makes sense to me and I'll be trying this out later!