DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations

How to write your own Matchers with ScalaTest

Jens Schauder user avatar by
Jens Schauder
·
Oct. 04, 11 · Interview
Like (0)
Save
Tweet
Share
6.35K Views

Join the DZone community and get the full member experience.

Join For Free

I just love the assertion syntax of ScalaTest. It’s easy to read and easy to write and looks like this:

23 should be >= (12)

Even if you know nothing about ScalaTest it should be easy to understand whats this assertion is about. But what when your assertions get more complex? Like this:

    new Frog().color.getGreen() should be >= (80)

Although this assertion certainly isn’t rocket science, it is not so easy to see what is getting tested here. How about this?

new Frog() should  be_Greenish

Now that is nice and clean and perfectly possible with ScalaTest. Of course we have to implement be_Greenish since ScalaTest doesn’t care so much about Frogs being green. Luckily the implementation is simple:

    object be_Greenish extends Matcher[Frog]{
        def apply (left : Frog) : MatchResult =
            MatchResult(left.color.getGreen >= 80, "The frog is not green enough", "The frog contains to much green" )
    }

should expects a Matcher of what ever comes before should. So be_greenish must be a Matcher[Frog]. The Matcher has one method which we need to implement: apply and it takes a Frog as an argument and returns a MatchResult which we can construct using boolean signifying if the frog passed the test represented by the matcher or not, and the messages to use when the test failed and when the test succeed but actually was supposed fail. This makes it possible to negate assertions using not. There is also a variation of MessageResult which takes two more messages as arguments. Those are used when assertions get combined using and or or. In these cases the failure message of a Matcher are only part of a longer sentence and therefore probably shouldn’t start with a capital letter.

This approach would works really nice if we were testing some behavior of our frog. Like its ability to jump. We could create matcher that allow us to write things like:

new Frog() should  jump (far)

jump would be a method taking a Distance as an argument and returning a Matcher[Frog]. far would be an instance of Distance.

But we really just want to test a property. This causes the weird name ‘be_Greenish’ with the odd underscore. There is a easier and therefore better way to write these matchers: BePropertyMatcher:

    object greenish extends BePropertyMatcher[Frog]{
        def apply(left : Frog) = BePropertyMatchResult(left.color.getGreen >= 80, "greenish")
    }

This allows us to write test like:

new Frog(Color.blue)  should not  be(greenish)

So whenever you write tests where the assertions are not trivial and possibly repeated in multiple tests consider to implement your own matchers. It’s easy and makes for way easier to read tests.

From http://blog.schauderhaft.de/2011/10/02/how-to-write-your-own-matchers-with-scalatest/

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • How To Build a Spring Boot GraalVM Image
  • Unlocking the Power of Elasticsearch: A Comprehensive Guide to Complex Search Use Cases
  • Best CI/CD Tools for DevOps: A Review of the Top 10
  • Top 10 Best Practices for Web Application Testing

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: