Is there an idiomatic way, that does not duplicate code and checks that an exception was thrown in Io when unit-testing?
So far:
threw := false
e := try(_method that should throw_)
e catch(Exception, threw = true)
if(threw not, fail("Should have thrown an Exception, but did not!"))
There is no built in expectation for that in Io's UnitTest. However, building a custom expectation isn't difficult at all, you could write this submit a pull request and use it just dandy.
Alternatively, if you're not hung up on using UnitTest, you can use my fork of iospec2 which has this expectation (and others) built in. My fork was done for my IoSpec project, so it's embedded with IoSpec. You'd be interested in the top-level iospec script and everything inside lib.
Related
I am trying to write unit test for this project
It appears that i need to refactor a lot and currently working on it. In order to test functions in project/api/handlers.go i was trying to write some unit test code however always taking error related with DB initializing. DB is from Psql Docker container. Error says given hostname is not valid, however without testing it works as no problem. Also, for Dockerized postgresql, container name is being used as hostname and this shouldn't be a problem.
The error is:
DB connection error: failed to connect to host=postgresdbT user=postgres database=worth2watchdb: hostname resolving error (lookup postgresdbT: no such host)
Process finished with the exit code 1
Anyway, i did a couple refactor and managed abstracting functions from DB query functions however this error still occurs and i cannot perform the test. So finally i decided to perform a totally blank test within same package simply checks with bcrypt package.
func TestCheckPasswordHash(t *testing.T) {
ret, err := HashPassword("password")
assert.Nil(t, err)
ok := CheckPasswordHash("password", ret)
if !ok {
t.Fail()
}
}
//HashPassword function hashes password with bcrypt algorithm as Cost value and return hashed string value with an error
func HashPassword(password string) (string, error) {
bytes, err := bcrypt.GenerateFromPassword([]byte(password), 4)
return string(bytes), err
}
//CheckPasswordHash function checks two inputs and returns TRUE if matches
func CheckPasswordHash(password, hash string) bool {
err := bcrypt.CompareHashAndPassword([]byte(hash), []byte(password))
return err == nil
}
However when I've tried to perform test for only TestCheckPasswordHash function with command of go test -run TestCheckPasswordHash ./api, it still gives same error. Btw, File is handlers_test.go, functions are at handlers.go file, package name is api for both .
There is no contact with any kind of DB related functions however i am having same error again and again. When i run this TestCheckPasswordHash code in another project or at project/util/util_test.go, it checks and passes as expected.
I don't know what to do, it seems that i cannot perform any test in this package unless figure this out.
Thanks in advance. Best wishes.
Was checking your repo, nice implementation, neat an simple good job!
I think your issue is in the init function, please try commenting it out and see if it work for that single test.
Is a bit complex to explain how the init function works without a graph of files as example but you can check the official documentation:
https://go.dev/doc/effective_go#init
PD: if this doesn't work please write me back
I've found the reason why this error occured and now it's solved.
This is partially related with Docker's working principle of how DB_Hostname must be declared but we can do nothing about it. So we need a better approach to overcome.
When go test command executed for (even) a function, Go testing logic checks whole package(not whole project) as per execution order, such as firstly variable declarations and init() function later. In case of calling an external package item, runtime detours that package for the item also.
Even if you are testing only an irrelevant function, you should consider that, before performing the test, Go runtime will evaluate whole package.
In order to prevent this, i wrapped the package level variables(even though they are in another package) that directly calls DB and cache. On initial stage, these can be allocated as a new variable. However, their connection will be ensured by main or main.init()
And now, prior to testing, all relevant variables (in same package or via external) are checked. Let's say if DB agent (redis.client or pgxpool.Pool) is needed, we are creating a new agent, compiler doesn't complain and testing begins. Agent will be operational only by a function call from main or somewhere we want to.
This is a better(may be not best) practice for a more maintainable code. Initialization of dependants should be able to be handled cautiously and in context with the functional needs. At least, with a simple refactoring, problem should be solvable.
What is the point of the REQUIRE_NOTHROW assertion? If I just put a statement and don't wrap it in any assertion macro it will fail if it throws anyway?
It's the difference between the TEST_CASE failing and an individual assertion failing. The REQUIRE macros ensure that the next lines aren't executed if they fail. Conversely, the CHECK macros can mark the test case as a failure but continue.
Consider this example:
REQUIRE_NOTHROW(parseInput(validInput));
REQUIRE_THROWS(parseInput(errorInput));
REQUIRE_THROWS(parseInput(NULL));
So we're explicitly requesting that passing valid input does not cause an exception, but bad input does. If we didn't use the REQUIRE_NOTHROW() macro, then the test would fail but then we'd need to decipher where it failed - an exception could have come from other lines of test code.
In our tests, we make extensive use of stubs, some of which create and throw exceptions. I'm finding that just instantiating an exception, is causing a stacktrace to show up when our tests run. This means that there's a large amount of unnecessary and confusing noise, as we don't care about these 'expected' exceptions. I've scoured the internet, but can't find anything about silencing these stacktraces (bare in mind, that actual exceptions, thrown elsewhere within the code, or by the framework, I'd like to still show traces for). Is this a common issue and has anyone found a way around it?
Sorry, with example:
val t = new Throwable("Expected exception")
val service = new AuthenticationService()(ExceptionThrowingClient(t))
Results in a test run with a stacktrace that looks something like this:
java.lang.Throwable: Expected exception
at services.auth.AuthenticationServiceSpec$$anonfun$4.apply(ServiceSpec.scala:104) ~[test-classes/:na]
at services.auth.AuthenticationServiceSpec$$anonfun$4.apply(ServiceSpec.scala:103) ~[test-classes/:na]
at org.specs2.mutable.SideEffectingCreationPaths$$anonfun$executeBlock$1.apply$mcV$sp(FragmentsBuilder.scala:292) ~[specs2-core_2.10-2.3.12.jar:2.3.12]
at org.specs2.mutable.SideEffectingCreationPaths$class.replay(FragmentsBuilder.scala:264) ~[specs2-core_2.10-2.3.12.jar:2.3.12]
at org.specs2.mutable.Specification.replay(Specification.scala:12) ~[specs2-core_2.10-2.3.12.jar:2.3.12]
Which traces back to the point of instantiation within the spec.
I was looking at scala.util.control.NonFatal. I can't find the source, but I believe it is something like this.
They are declaring LinkageError as Fatal ...
Tomcat (at least last few years I used it) always returned 500 on catch Throwable, rather than crashing on certain kinds of errors. So do many other systems that make a best effort to always return something to the client.
So, my end question is when would you use NonFatal instead of making a best-effort attempt to provide some response?
As an example, now Futures in Twitter's Future library end up not resolving on NoSuchMethodError so my Future no longer resolves as failed with a Throwable but instead throw up the stack (differently from RuntimeException). In fact, in the open source Finagle stack, a NoSuchMethodError will cause the client socket connection to close on the client with no 500 http error back to customer. Customer then thinks 'hmm, network issue maybe ... why did my socket close'
So far, it has caused me nothing but issues and I admit to be a little frustrated, but need to be open to more use cases. For years, KISS and treating every Throwable in the catchall as non fatal has worked, but NonFatal is implying there are use-cases where we should do something different.
The source code of NonFatal is linked from the API docs.
Fatal errors are those from which your system or the JVM will most likely not recover correctly, so catching those errors is not a good idea.
The sub-classes of LinkageError are: ClassCircularityError, ClassFormatError, ExceptionInInitializerError, IncompatibleClassChangeError, NoClassDefFoundError, UnsatisfiedLinkError, VerifyError. These all occur when your class path is broken, there are invalid or binary incompatible class files. It's safe to assume that your entire system is broken if these happen at runtime.
To answer the question: You should "let it crash". Always use a NonFatal pattern match when you need a catch-all clause. It will also do you the favour and handle control-flow related exceptions correctly (e.g. NonLocalReturnControl).
Note that unlike the old source you link to, StackOverflowError is not non-fatal any longer, the decision was revised in Scala 2.11 as per SI-7999.
I got this cute error, that has no stack trace associated with it in play's log file (nor in the console).
[ERROR] [03/14/2015 19:36:46.713] [play-akka.actor.default-dispatcher-7] [ActorSystem(play)] Uncaught error from thread [play-akka.actor.default-dispatcher-7] (scala.runtime.NonLocalReturnControl)
[error] a.a.ActorSystemImpl - Uncaught error from thread [play-akka.actor.default-dispatcher-7]
scala.runtime.NonLocalReturnControl: null
Does this represent a promise/future that crashed, but has no thread any longer waiting for it other than akka's dispatcher? how can I nonetheless trace the error in my code without attaching a debugger session?
Attaching a debugger, it seems that using a return inside Future map composition caused the NonLocalReturnControl error. Oddly and unfortunately though, the stack trace doesn't propagate to the console/log in this case in my case. The stack at the moment a NonLocalReturnControl is created can be seen in a debugger, but akka/play somehow don't provide it.
Alas, this type of error's stack trace is suppressed by default. Turns out quite amazingly that scala internally implements function return value propagation by internally throwing and catching this exception type (up until Scala 2.11 at least). Hence the special suppression... Tough luck.
The same exception arises when using return in a future, which is obviously a mistake, but the internal architecture's use of this suppressed exception, makes debugging this particular case, well, suck. Check you don't use return in asynchronous code if you get this error, and avoid using return as much as you can so it is less likely this will pop up in your code when turned asynchronous.