The detection of a //test: <class name> annotation at the beginning of a Test Specification in Scala questions seems broken.

When the Test Specification only consists of a line break (pressing enter once in the empty field) and one clicks on “Compile” the view shows the error no first line and the editing and syntax highlighting capabilities are gone until the page is reloaded.

More importantly the useful error message of the missing annotation will not be shown if the Test Specification contains valid code:

import org.scalatest.Suite
import Solution._

class Test extends Suite {
  // tests here...
}

yields

Status: RunningFailure
Test score: 0/-1

But using a completely empty Test Specification (not even a linebreak) yields

Status: CompilationFailure
No //test: <ClassName> annotation in test file

For usability reasons it would be nice if the requirement of this test annotation would be more verbose.

Submitted by Florian Jakob on 8 April 2013 at 19:01

Yes, that is bad error handling. I’ll look into improving this in the future. But it is not a breaking error, right?

Perhaps I mixed two different issues into one.

1. Not announcing the No //test: <ClassName> annotation in test file if there is none, but nevertheless valid code, is a usability issue.

2. But the fact, that the whitespace-only Test Specification messes up the UI on compile to an extend that a reload of the page is necessary, seems broken to me. Maybe I’m getting the meaning of broken wrong, but it feels like a crash of the editor which must then be restarted.

I assumed the whitespace-issue has something to do with the detection of the test annotation, but it may also be completely independant.

I will work on better error reporting for 1.

Are you still experiencing 2? I suspect it was related to another problem that I fixed yesterday.

Sadly yes, I’m still experiencing the whitespace problem. I’ve created a quick screencast to better illustrate the problem.

Thanks for the screencast. I will investigate.

Relates to WebDSL behaviour, replacing the whole form (including the tabs with ace editors) on validation exception which occurs in the action code of the compile and other action-buttons. No clean workarounds for this, we may adapt WebDSL to replace buttons only instead of whole form.

Eventually it is fixed by elaborating on the compiler error output instead of validation within the webdsl code. Also changed the error message to emphasize that the test class specification should be on the first line.