I am learning pytest, which gives me an advantage: I'm utterly clueless, so I can I tell you what I found confusing and how I got around it.
In https://docs.pytest.org/en/latest/fixture.html#, there are two example python files: test_module.py and test_smtpsimple.py. What I found confusing about the examples is there are two methods, smtp_connection.ehlo() and smtp_connection.noop(). It is not intuitively obvious that these are methods of objects of class smtplib.SMTP. Of course, they are. I had to dig through some software to figure that out.
In https://docs.pytest.org/en/latest/fixture.html#, there are two example python files: test_module.py and test_smtpsimple.py. What I found confusing about the examples is there are two methods, smtp_connection.ehlo() and smtp_connection.noop(). It is not intuitively obvious that these are methods of objects of class smtplib.SMTP. Of course, they are. I had to dig through some software to figure that out.
So I modified the code with some comments to make it easier, I hope, for somebody learning pytest.
def test_noop(smtp_connection):
# See https://docs.python.org/3/library/smtplib.html#smtp-objects
# The documentation there says that the noop method is not documented there.
response, msg = smtp_connection.noop()
assert response == 250
assert 0 # for demo purposes
and
def smtp_connection():
import smtplib
# This isn't clear from https://docs.pytest.org/en/latest/fixture.html but smtplib has
# at least two attributes: ehlo and noop
print ( dir(smtplib.SMTP), file=sys.stderr )
# Return an object of class smtplib.SMTP which has methods ehlo and noop
return smtplib.SMTP("smtp.gmail.com", 587, timeout=5)
def test_ehlo(smtp_connection):
# smtp_connection is an object of type smtplib.SMTP.
# See https://docs.python.org/3/library/smtplib.html#smtp-objects
# The documentation there says that the noop method is not documented there.
response, msg = smtp_connection.ehlo()
assert response == 250
assert 0 # for demo purposes
To make it even clearer, I might print the object id of smtp_connection as it works its ways through the code. That might be overkill.
Related
I don't quite understand why this is not failing:
def hello(name: str) -> int:
ending:int = '!!!'
return f'Hello {name} {ending}'
print(hello('John')) # Hello John !!!
And if there is already possibility to strong type python?
The reason is explained in PEP 484 by Guido himself:
It should also be emphasized that Python will remain a dynamically typed language, and the authors have no desire to ever make type hints mandatory, even by convention.
So the answer is NO. Type hints are only hints. They help to indicate what type of data a variable or function should/may contain/returns/etc. It wasn't designed to transform Python into a statically typed language.
As I wrote in comment it is nice to use mypy myproject.py to run it before project/code run. Then you could verify data types structure and correct flow.
I have a macro that puts catch-all functions in the end of the module, so resulting module looks something like:
defmodule Module1 do
<module body>
## Generated catch-all functions
def fun1(_, _), do: :ok
## ..more catch-all functions...##
end ## of module
The problem I'm trying to solve is to suppress warnings
"this clause cannot match because a previous clause at line XX always matches" in case the user of macro will have, for instance
def fun1(arg1, arg2), do: ...
in the body of the module.
I guess I can go through module's body AST and do some analysis of function signatures before generating catch-all functions, but it seems to be a lot of work. Is there any other way?
(I think you know this solution but maybe it could be useful to other SO users to answer this question :) )
As José have said, it's not a very good practice to hide too much in the code as it can lead to surprises (hidden code can do something you do not expect t to do) and can even limit you (in this particular case, if you have un-explicit catchall, you can't get rid of it...).
I thing the best approach is to explicitly use a macro to generate all the boilerplate code. One line to call the macro is not as much boilerplate ;)
Example implementation:
https://gist.github.com/mprymek/73f878e103f60d6d89e2
Just ran into this sample code learning about Commands in Scalatra:
protected def handle: Handler = {
case c: CreateTodoCommand =>
add(newTodo(~c.name.value))
}
In this particular case, what exactly is the relevance of ~ in ~c.name.value? Not sure where to find more documentation on this particular symbol.
In Scala:
~x
translates to
x.unary_~
(this also applies to +,- and ! as explained in this post). So your example translates to:
add(newTodo(c.name.value.unary_~))
The documentation can hence be found at the type of value.
it seems to be related to the block of code commented out in here: https://github.com/scalatra/scalatra/blob/2.2.x_2.9/core/src/main/scala/org/scalatra/package.scala
that is the only unary tilde operator if found that could be working here. the others seem to mainly be bitwise not operators
It actually seems that this might also be some import from scalaz library, tho the import statements are missing. similar uses of ~Option[_] can be found elsewhere as well...
I need to produce same result in Perl that hash_hmac('ripemd160', $data, $key) produces in PHP
Managed to trace it down to two perl modules, just cant get them working together...
Digest::HMAC and Crypt::RIPEMD160
use Crypt::RIPEMD160;
use Digest::HMAC;
$hmac = Digest::HMAC->new('bar', 'Crypt::RIPEMD160');
$hmac->add('foo');
$digest = $hmac->digest;
anyone got any ideas what am i doing wrong?
If i use the code above i get following error:
Can't call method "add" on an undefined value at /usr/lib64/perl5/vendor_perl/5.12.4/Digest/HMAC.pm line 28.
Since i was unable to pass the hash function reference in the code above, after looking at the HMAC module at the hmac function i thought i could write it in my code direct:
my $data = 'bar';
my $key = 'foo';
$block_size = 160;
$block_size ||= 64;
$key = Crypt::RIPEMD160->hash($key) if length($key) > $block_size;
my $k_ipad = $key ^ (chr(0x36) x $block_size);
my $k_opad = $key ^ (chr(0x5c) x $block_size);
my $digest = Crypt::RIPEMD160->hash($k_opad, Crypt::RIPEMD160->hash($k_ipad, $data));
this does produce a hash but still a wrong one
PHP generated hash: isceebbf5cd5e34c888b493cf7f7c39a7b181b65a3
The perl hash: hash21a2fa2bf39fd99d4c9cdf147added69c32d45f9e
To be honest i dont care how its done and what modules are used as long as I get same hash as the php function produces... at this point I am tempted writing a php script that i call from perl just to get that hash... :( as I am runing out of ideas...
The Digest::HMAC only includes Digest::HMAC_MD5 and Digest::HMAC_SHA1. However, I took a look at the Perl code for Digest::HMAC_MD5. The whole thing is about 20 lines of code. It basically creates two methods:
sub hmac_md5 {
hmac($_[0], $_[1], \&md5, 64);
}
and
sub hmac_md5_hex {
unpack("H*", &hmac_md5);
}
That's pretty much the entire program.
If you forget about the object oriented style of the package, and use the functional style, it looks like this might work for you:
hmac($data, $key, \&ripemd160, 160);
or maybe just:
hmac($data, $key \&ripemd160);
In fact, that's documented on the CPAN Digest::HMAC page itself.
I am perhaps a bit late in this discussion but when talking about Crypt::Digest::RIPEMD160 (I am the author of this module :) you can easily create HMAC with Crypt::Mac::HMAC from the same family of modules.
It is as simple as:
use Crypt::Mac::HMAC 'hmac';
$hmac_raw = hmac('RIPEMD160', $key, $data);
The reason your code doesn't work is that, while the interface provided by Crypt::RIPEMD160 looks similar to the standard Digest interface, it's not quite compatible: in particular, the reset() method of Crypt::RIPEMD160 apparently doesn't return a reference to the object it's called on, and the code in Digest::HMAC happens to rely on that detail.
This incompatibility would be a trivial things to fix by slightly tweaking either module, either to add the missing return value to Crypt::RIPEMD5 or to make Digest::HMAC less reliant on needless method chaining. The latter would be as easy as changing the line:
$self->{hasher}->reset->add($self->{k_opad}, $inner_digest);
in Digest::HMAC to:
$self->{hasher}->reset;
$self->{hasher}->add($self->{k_opad}, $inner_digest);
(Of course, I'm not suggesting that you do this yourself, although you could report the issue to the maintainers of those modules.)
However, with both modules as they currently are, it just won't work. The solutions I'd recommend would be to either use the non-OO interface, as David W. suggests, or try the newer Crypt::Digest::RIPEMD160 module, which properly implements the Digest interface and should play nicer with Digest::HMAC.
Edit:
Actually, David W.'s suggestion won't work as given, because Crypt::RIPEMD160 doesn't export a non-OO ripemd160() function. You could, however, easily create one:
use Crypt::RIPEMD160;
sub ripemd160 {
return Crypt::RIPEMD160->hash( join "", #_ );
}
and then use it like this:
use Digest::HMAC qw( hmac );
sub hmac_ripemd160 {
return hmac( #_[0, 1], \&ripemd160, 64 );
}
(Yes, 64 bytes is the correct block size from HMAC-RIPEMD160, since the input block length of RIPEMD160 is 16 32-bit words, which equals 512 bits or 64 bytes. In practice, using the wrong input block size is very unlikely to cause any issues, other than for interoperability of course, but the security proof of the HMAC construction assumes, for simplicity, that the key is padded to be exactly one input block long. Thus, and in order to ensure that all implementations of HMAC-RIPEMD160 produce the same output for the same key and message, it's best to stick to this rule.)
Edit 2: OK, I tried to test the code I posted above against the HMAC-RIPEMD160 test vectors from RFC 2286, and just could not get the results to match. What I finally realized was two things:
The non-OO hmac() function exported by Digest::HMAC assumes that the custom hash function passed to it will accept multiple parameters and concatenate them. My original implementation of the ripemd160() wrapper above did not (but I fixed it so that now it does). This is arguably a bug in Digest::HMAC, or at least in its documentation.
The Crypt::RIPEMD160 module comes with the submodule Crypt::RIPEMD160::MAC, which already implements HMAC-RIPEMD160, even though, for some perverse reason, the documentation doesn't actually use the name HMAC. If you look at the code, though, or just compare the output to the official test vectors, that's indeed exactly what it does.
I'm trying to test-drive some Scala code using Specs2 and Mockito. I'm relatively new to all three, and having difficulty with the mocked methods returning null.
In the following (transcribed with some name changes)
"My Component's process(File)" should {
"pass file to Parser" in new modules {
val file = mock[File]
myComponent.process(file)
there was one(mockParser).parse(file)
}
"pass parse result to Translator" in new modules {
val file = mock[File]
val myType1 = mock[MyType1]
mockParser.parse(file) returns (Some(myType1))
myComponent.process(file)
there was one(mockTranslator).translate(myType1)
}
}
The "pass file to Parser" works until I add the translator call in the SUT, and then dies because the mockParser.parse method has returned a null, which the translator code can't take.
Similarly, the "pass parse result to Translator" passes until I try to use the translation result in the SUT.
The real code for both of these methods can never return null, but I don't know how to tell Mockito to make the expectations return usable results.
I can of course work around this by putting null checks in the SUT, but I'd rather not, as I'm making sure to never return nulls and instead using Option, None and Some.
Pointers to a good Scala/Specs2/Mockito tutorial would be wonderful, as would a simple example of how to change a line like
there was one(mockParser).parse(file)
to make it return something that allows continued execution in the SUT when it doesn't deal with nulls.
Flailing about trying to figure this out, I have tried changing that line to
there was one(mockParser).parse(file) returns myResult
with a value for myResult that is of the type I want returned. That gave me a compile error as it expects to find a MatchResult there rather than my return type.
If it matters, I'm using Scala 2.9.0.
If you don't have seen it, you can look the mock expectation page of the specs2 documentation.
In your code, the stub should be mockParser.parse(file) returns myResult
Edited after Don's edit:
There was a misunderstanding. The way you do it in your second example is the good one and you should do exactly the same in the first test:
val file = mock[File]
val myType1 = mock[MyType1]
mockParser.parse(file) returns (Some(myType1))
myComponent.process(file)
there was one(mockParser).parse(file)
The idea of unit testing with mock is always the same: explain how your mocks work (stubbing), execute, verify.
That should answer the question, now a personal advice:
Most of the time, except if you want to verify some algorithmic behavior (stop on first success, process a list in reverse order) you should not test expectation in your unit tests.
In your example, the process method should "translate things", thus your unit tests should focus on it: mock your parsers and translators, stub them and only check the result of the whole process. It's less fine grain but the goal of a unit test is not to check every step of a method. If you want to change the implementation, you should not have to modify a bunch of unit tests that verify each line of the method.
I have managed to solve this, though there may be a better solution, so I'm going to post my own answer, but not accept it immediately.
What I needed to do was supply a sensible default return value for the mock, in the form of an org.mockito.stubbing.Answer<T> with T being the return type.
I was able to do this with the following mock setup:
val defaultParseResult = new Answer[Option[MyType1]] {
def answer(p1: InvocationOnMock): Option[MyType1] = None
}
val mockParser = org.mockito.Mockito.mock(implicitly[ClassManifest[Parser]].erasure,
defaultParseResult).asInstanceOf[Parser]
after a bit of browsing of the source for the org.specs2.mock.Mockito trait and things it calls.
And now, instead of returning null, the parse returns None when not stubbed (including when it's expected as in the first test), which allows the test to pass with this value being used in the code under test.
I will likely make a test support method hiding the mess in the mockParser assignment, and letting me do the same for various return types, as I'm going to need the same capability with several return types just in this set of tests.
I couldn't locate support for a shorter way of doing this in org.specs2.mock.Mockito, but perhaps this will inspire Eric to add such. Nice to have the author in the conversation...
Edit
On further perusal of source, it occurred to me that I should be able to just call the method
def mock[T, A](implicit m: ClassManifest[T], a: org.mockito.stubbing.Answer[A]): T = org.mockito.Mockito.mock(implicitly[ClassManifest[T]].erasure, a).asInstanceOf[T]
defined in org.specs2.mock.MockitoMocker, which was in fact the inspiration for my solution above. But I can't figure out the call. mock is rather overloaded, and all my attempts seem to end up invoking a different version and not liking my parameters.
So it looks like Eric has already included support for this, but I don't understand how to get to it.
Update
I have defined a trait containing the following:
def mock[T, A](implicit m: ClassManifest[T], default: A): T = {
org.mockito.Mockito.mock(
implicitly[ClassManifest[T]].erasure,
new Answer[A] {
def answer(p1: InvocationOnMock): A = default
}).asInstanceOf[T]
}
and now by using that trait I can setup my mock as
implicit val defaultParseResult = None
val mockParser = mock[Parser,Option[MyType1]]
I don't after all need more usages of this in this particular test, as supplying a usable value for this makes all my tests work without null checks in the code under test. But it might be needed in other tests.
I'd still be interested in how to handle this issue without adding this trait.
Without the full it's difficult to say but can you please check that the method you're trying to mock is not a final method? Because in that case Mockito won't be able to mock it and will return null.
Another piece of advice, when something doesn't work, is to rewrite the code with Mockito in a standard JUnit test. Then, if it fails, your question might be best answered by someone on the Mockito mailing list.