ScalaTest-related videos

Simplicity in Scala Design

In this talk from the Northeast Scala Symposium on Feb 8, 2013, Bill Venners focuses on how to achieve simplicity in Scala library, DSL, and application design. It highlights general principles that can be applied to any programming language, and shows specific techniques that can be used in Scala to "implement" the general principles. This talk gives you a set of concrete guidelines (which guide the design of ScalaTest and Scalactic) that can help you manage complexity in your Scala projects.

  The guidelines from this talk
  • Design for busy teams.
  • Make it obvious, guessable, or easy to remember.
  • Design for readers, then writers.
  • Make errors impossible, or difficult.
  • Exploit familiarity.
  • Document with examples.
  • Minimize redundancy.
  • Maximize consistency.
  • Use symbols when your users are already experts in them.
  • Minimize the magic.

The Trouble with Tests

Tests provide benefits, but also incur costs. Tests can help you achieve and maintain desired levels of software quality, but they take time (and therefore cost money) to write, compile, and run. They can give you confidence to perform needed refactoring, but can slow you down during refactors that break many tests. And although they can help you find bugs, they can't prove the absence of bugs.

So how do you maximize the return on your investment in tests? In this talk from the ScalaDays conference on June 17, 2014, Bill Venners, lead developer of ScalaTest, tackles this question and give his opinions. You'll come away with a set of specific guidelines that can help you decide how best to employ testing in your projects.

  The guidelines from this talk
  • Think of programming as investing.
  • Write focused tests with descriptive names.
  • Beware duplication in tests!
  • Don't overspecify in tests.
  • Transform human errors into type errors.
  • Throw exceptions only at humans, never at code.
  • Minimize pre-conditions.

And on tests versus types:

Tests can only find your code not guilty. They can't prove it innocent.
Types can only "prove innocence" to the extent they are tested.

Equality for All

The Java platform defines a notion of universal equality in the equals method of java.lang.Object: because the type of the parameter passed to equals is java.lang.Object, any object can be compared for equality with any other object. This allows different types that represent the same (or compatible) concepts to be compared for equality (such as Int and BigInt, or Vector[Int] and List[Int]), but also allows comparisons to compile that will always fail at runtime (such as Int and String).

In this talk from the Scala by the Bay conference on August 8, 2014, Bill Venners discusses work in progress on ScalaTest and Scalactic to make equality comparisons in Scala safer.

  Highlights from this talk
  • Equivalence classes in Set theory, Java, and Scala.
  • Java's equals contract.
  • Cooperative equality.
  • Alternate equality.
  • Candidate rules for equality comparison type errors.
  • How to deal with implicit conversions.
  • "Enabled" equality.

Implicit Conversions => Implicit Parameters

In this talk from the ScalaExchange conference on Dec 2, 2013, Bill Venners tells the story of the journey from a design that leaned towards implicit conversions in ScalaTest 1.0 to one that emphasizes implicit parameters in ScalaTest and ScalaUtils 2.0. Using primarily demos in the Scala REPL, Bill shows several use cases and applications of implicit parameters that will help you understand the tradeoffs between implicit conversions and parameters and how to take advantage of implicit parameters in your own designs.

  Highlights of this talk
  • Implicit parameters are good for configuring, customizing, constraining, and enabling
  • Patience configuration for eventually
  • Better error messages with assert macros
  • Normalization typeclass
  • Equality typeclass
  • Tolerance with +-
  • Explicitly DSL
  • Tunable type checks with ===
  • Matcher syntax enablers
  • Containing and Aggregating typeclasses

Hidden Gems in ScalaTest

ScalaTest 2.0 is a vast enough forest that it is hard to see all the useful trees. In this talk from the ScalaExchange conference on Dec 3, 2013, Bill Venners guides you through ScalaTest 2.0 by pointing out lesser-known features of the testing toolkit that can help you get stuff done. You'll gain insight into what ScalaTest offers, why ScalaTest is designed the way it is, and how you can get more out of it.

  Highlights of this talk
  • The Length typeclass and a puzzle
  • Something interesting to do with matchers that would give away the puzzle if I said more
  • Inspecting nested collections with forAll, forEvery, forAtMost, forAtLeast, forExactly, forBetween.
  • Inspector shorthands all, every, no, atMost, atLeast, exactly, between.
  • Annotating test classes to tag all tests.
  • Help for hanging or flickering tests.
  • Getting the word out with info, markup, note, and alert.
  • Reminders of failed and canceled tests in "string" Reporters.
  • How lazy MatchResults killed three birds with one brush stroke.

ScalaTest is brought to you by Bill Venners and Artima.
ScalaTest is free, open-source software released under the Apache 2.0 license.

If your company loves ScalaTest, please consider sponsoring the project.

Copyright © 2009-2024 Artima, Inc. All Rights Reserved.

artima