<div dir="ltr"><span style="font-size:13px">Thanks for your response and an interesting article! </span><div style="font-size:13px"><br></div><div style="font-size:13px">@Stan </div><div style="font-size:13px">Generally I agree with your opinion about Mockacks (people definitely tend to overuse them and confuse them with Stubs) though I wouldn't "scratch them off menu" completely because of that. </div><div style="font-size:13px">I find equalization between unit and integration tests rather controvertial. E.g. It's hard to imagine TDD with tests demanding full context, new condition of system and hitting the database each time. </div><div style="font-size:13px"><br></div><div style="font-size:13px">In my opinion a well done unit test is characterized by the following:</div><div style="font-size:13px">1. has only one reason to fail;</div><div style="font-size:13px">2. is independent of other tests - so that it may be launched in parallel with them;</div><div style="font-size:13px">3. last but not least - it's fast - which is critical for TDD! </div><div style="font-size:13px"><br></div><div style="font-size:13px">I love Arquillian from the first sight (I use it to do integration test) but I would never use it to unit tests. Of course, you're invited to make me change my mind. :) </div><div style="font-size:13px"><br></div><div style="font-size:13px">@Stian</div><div style="font-size:13px">"I agree it wouldn't hurt to have unit tests as well, but they are generally a pain to maintain" </div><div style="font-size:13px">In the subject of problems with maintaining tests I recommend you to listen to a lecture given by my friend - about tricky things in TDD. It's available here: <a href="https://vimeo.com/120572733" target="_blank">https://vimeo.com/120572733</a></div><div style="font-size:13px"><br></div><div style="font-size:13px">"Mocks make things even worse in that regard." </div><div style="font-size:13px">Come on, don't be obsessed with these Mocks! :P I shouldn't have mentioned about it… ;) </div><div style="font-size:13px"><br></div><div style="font-size:13px">"Personally I see unit tests and mocks more as a great development tool than actual quality assurance" </div><div style="font-size:13px">Well, I think that if the unit tests have helped you to write a good working code than it's just another proof of their reliability… ;) </div><div style="font-size:13px"><br></div><div style="font-size:13px">"End of the day what you care about is that your login page and your rest services behaves as expected there's just no need for unit tests"</div><div style="font-size:13px">Buisness value. :) Personally, I'm fully satisfied with my work only if the code I've written is clean and well tested. Furthermore, I prefer clean, tested but not error-free code than working one, which is embroiled and unclear. </div><div style="font-size:13px"><br></div><div style="font-size:13px">Best regards, </div><div style="font-size:13px">Andrzej </div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-10-27 15:58 GMT+01:00 Stian Thorgersen <span dir="ltr"><<a href="mailto:sthorger@redhat.com" target="_blank">sthorger@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Integration tests have many disguises, some are good others are bad. As Keycloak is not a framework or set of libraries, but a ready to use service it's a lot more important that we test the real thing than test individual bits and pieces.<div><br></div><div>I agree it wouldn't hurt to have unit tests as well, but they are generally a pain to maintain. Especially if you want to refactor something. Mocks make things even worse in that regard. Personally I see unit tests and mocks more as a great development tool than actual quality assurance. End of the day what you care about is that your login page and your rest services behaves as expected there's just no need for unit tests.</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On 27 October 2015 at 04:26, Stan Silvert <span dir="ltr"><<a href="mailto:ssilvert@redhat.com" target="_blank">ssilvert@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>You should never use mocks again. I
elaborated on this topic in Bill's blog several years ago and he
wrote a followup article:<br>
<a href="http://bill.burkecentral.com/2012/05/01/mocks-are-a-mockery/" target="_blank">http://bill.burkecentral.com/2012/05/01/mocks-are-a-mockery/</a><div><div><br>
<br>
On 10/27/2015 4:41 AM, Andrzej Goławski wrote:<br>
</div></div></div><div><div>
<blockquote type="cite">
<div dir="ltr">
<div>"For example for federation, you need realm and user DB and
you need to have realm configured with federation Provider"</div>
<div><br>
</div>
<div>In such cases you can use mocks, stubs and object
factories.</div>
<div><br>
</div>
<div>"There is not much you can test within single module"</div>
<div><br>
</div>
<div>IMHO there are still few things which would be nice to
test. Look at the first class in the module LDAP Config for
example. There are few comments suggesting refactoring it in
the feature. I find refactoring single class or classes with
heavy integration test painful and insufficient. Look at
spring framework code. There are plenty of small unit tests
which test only one thing so that it is really well tested as
a whole! I think good testing is especially important in case
of open source - where everybody adds some code. For instance
me :) For me LDAP it is a new topic, but I would like to add
some code to this part ... so I expect to make o a lot of
mistakes :D</div>
<div>"Btv. what's your plan for KEYCLOAK-1797"</div>
<div>And now the hardest part :) As I said, I'm new in this
topic (LDAP) so I decided to wrap my head around it for a
while - can you reccommend me any reading materials suitable
for beginners?</div>
<div><br>
</div>
<div>"And in your LDAP environment, is it often that new role is
added as member to some other roles?"</div>
<div><br>
</div>
<div>No .. but it is critical in my company. </div>
<div><br>
</div>
<div>"I wonder if we need to always do "deep" search in runtime,
or if we can instead do it just at some point and rely on
Keycloak composite roles . If you always need deep search and
do something based on it, it will be good to have a flag in
configuration, which will allow to disable it (for performance
reasons)."</div>
<div><br>
</div>
<div>Thank you for the hint :) I couldn't agree more. </div>
<div><br>
</div>
<div>
<div style="font-size:13px">Best regards,</div>
<div style="font-size:13px"><br>
</div>
<div style="font-size:13px"> Andrzej</div>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">2015-10-26 14:11 GMT+01:00 Marek
Posolda <span dir="ltr"><<a href="mailto:mposolda@redhat.com" target="_blank">mposolda@redhat.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>We prefer integration tests as you usually need more
things to have available. For example for federation,
you need realm and user DB and you need to have realm
configured with federationProvider. There is not much
you can test within single module, so we have just very
simple tests in individual modules (like LDAPDnTest or
PasswordPolicyTest), but most of the stuff is tested in
testsuite. For KEYCLOAK-1797 I prefer to take a look at
<span style="background-color:#e4e4ff">LDAPRoleMappingsTest
and possibly add new test methods here.<br>
<br>
Btv. what's your plan for KEYCLOAK-1797 ? And in your
LDAP environment, is it often that new role is added
as member to some other roles? I wonder if we need to
always do "deep" search in runtime, or if we can
instead do it just at some point and rely on Keycloak
composite roles . If you always need deep search and
do something based on it, it will be good to have a
flag in configuration, which will allow to disable it
(for performance reasons).<span><font color="#888888"><br>
<br>
Marek<br>
<br>
</font></span></span>
<div>
<div>On 26/10/15 08:55, Andrzej Goławski
wrote:<br>
</div>
</div>
</div>
<div>
<div>
<blockquote type="cite">
<div dir="ltr">
<div>Hi Marek,</div>
<div><br>
</div>
<div>Thanks for reply!</div>
<div>I saw those test, but personally I prefer
unit tests over integrated tests:)</div>
<div>I really recommend this: <a href="https://vimeo.com/80533536" target="_blank">https://vimeo.com/80533536</a></div>
<div><br>
</div>
<div>Best Regards,</div>
<div> Andrzej</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">2015-10-26 8:41 GMT+01:00
Marek Posolda <span dir="ltr"><<a href="mailto:mposolda@redhat.com" target="_blank">mposolda@redhat.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>Hi,<br>
<br>
most of the tests are in the
testsuite/integration or
testsuite/integration-arquillian, not in
the modules itself. For the federation and
ldap, you can take a look especially to
package org.keycloak.testsuite.federation
.<br>
<br>
Marek <br>
<div>
<div> <br>
On 25/10/15 21:51, Andrzej Goławski
wrote:<br>
</div>
</div>
</div>
<blockquote type="cite">
<div>
<div>
<div dir="ltr">
<div>Hi everyone!</div>
<div><br>
</div>
<div>I decided to implement
KEYCLOAK-1797 and started to look
at the code (federation/ldap). I
noticed lack of unit tests without
which refactoring may be very
error prone. I like writing test
so I can write tests for that
part. What are you thinking about
it??</div>
<div><br>
</div>
<div>
<div>Best Regards,</div>
<div> Andrzej</div>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
</div>
</div>
<pre>_______________________________________________
keycloak-dev mailing list
<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></pre>
</blockquote>
<br>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
keycloak-dev mailing list
<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></pre>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
keycloak-dev mailing list<br>
<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
keycloak-dev mailing list<br>
<a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br></blockquote></div><br></div>