<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Developers, Developers, Developers! &#187; EasyMock</title>
	<atom:link href="http://maksim.sorokin.dk/it/tag/easymock/feed/" rel="self" type="application/rss+xml" />
	<link>http://maksim.sorokin.dk/it</link>
	<description>Maksim Sorokin IT Blog</description>
	<lastBuildDate>Sun, 05 Feb 2012 19:37:38 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.3</generator>
		<item>
		<title>Eclipse &#8220;Favorites&#8221; and JUnit 4 Static Imports Revised</title>
		<link>http://maksim.sorokin.dk/it/2010/03/23/eclipse-favorites-and-junit-4-static-imports-revised/</link>
		<comments>http://maksim.sorokin.dk/it/2010/03/23/eclipse-favorites-and-junit-4-static-imports-revised/#comments</comments>
		<pubDate>Tue, 23 Mar 2010 17:54:14 +0000</pubDate>
		<dc:creator>Maksim Sorokin</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[EasyMock]]></category>
		<category><![CDATA[Eclipse]]></category>
		<category><![CDATA[JUnit 4]]></category>

		<guid isPermaLink="false">http://maksim.sorokin.dk/it/?p=102</guid>
		<description><![CDATA[After some time of using static imports workaround for JUnit 4 and EasyMock described earlier I came to the conclusion, that editing import "favorites" is not a good idea. The problem is that when you include a class with static methods in Eclipse "favorites", then in Content Assistant you see hundred of those static methods. [...]]]></description>
			<content:encoded><![CDATA[<p>After some time of using static imports workaround for JUnit 4 and EasyMock <a href="http://maksim.sorokin.dk/it/2010/02/12/eclipse-and-junit-4-static-imports/">described earlier</a> I came to the conclusion, that editing import "favorites" is not a good idea.</p>
<p>The problem is that when you include a class with static methods in Eclipse "favorites", then in Content Assistant you see hundred of those static methods. This maybe somewhat inconvenient. Moreover, Content Assistant hangs a bit longer before appearing.</p>
<p>From now on I am directly using class name like <code>Assert.assert..</code> or <code>EasyMock.expect..</code> instead of using static imports.</p>
]]></content:encoded>
			<wfw:commentRss>http://maksim.sorokin.dk/it/2010/03/23/eclipse-favorites-and-junit-4-static-imports-revised/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Hard-To-Mock Objects</title>
		<link>http://maksim.sorokin.dk/it/2010/03/12/hard-to-mock-objects/</link>
		<comments>http://maksim.sorokin.dk/it/2010/03/12/hard-to-mock-objects/#comments</comments>
		<pubDate>Fri, 12 Mar 2010 18:08:20 +0000</pubDate>
		<dc:creator>Maksim Sorokin</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[EasyMock]]></category>
		<category><![CDATA[Java]]></category>
		<category><![CDATA[testing]]></category>

		<guid isPermaLink="false">http://maksim.sorokin.dk/it/?p=93</guid>
		<description><![CDATA[What to do with objects, which are hard to mock? For instance, you are working with org.w3c.dom. Suddenly you need a feature of extracting elements by tagname only from the first level. Since by default method getElementsByTagName returns all the elements from all levels, you decide to write your own method: public List getChildElementsByTagnameFromFirstLevel(Element parentEl, [...]]]></description>
			<content:encoded><![CDATA[<p>What to do with objects, which are hard to mock?</p>
<p>For instance, you are working with <code>org.w3c.dom</code>. Suddenly you need a feature of extracting elements by tagname only from the first level. Since by default method <code>getElementsByTagName</code> returns all the elements from all levels, you decide to write your own method: <span id="more-93"></span></p>
<pre class="brush: java; title: ;">
public List getChildElementsByTagnameFromFirstLevel(Element parentEl, String tagname) {
  List childrenEls = new ArrayList();

  NodeList nl = parentEl.getChildNodes();
  for (int i = 0; i &amp;lt; nl.getLength(); i++) {
    if (nl.item(i).getNodeName().equals(tagname)) {
      childrenEls.add((Element) nl.item(i));
    }
  }

  return childrenEls;
}
</pre>
<p>In order to test this method, you have to create mocks. Let say we use <a href="http://easymock.org/">EasyMock</a> for that:</p>
<pre class="brush: java; title: ;">
@Test
public void testGetChildElementsByTagnameFromFirstLevel() {
  String TAGNAME = &quot;TAGNAME&quot;;

  Element n1 = EasyMock.createMock(Element.class);
  EasyMock.expect(n1.getNodeName()).andReturn(TAGNAME);
  Element n2 = EasyMock.createMock(Element.class);
  EasyMock.expect(n2.getNodeName()).andReturn(&quot;&quot;);
  Element n3 = EasyMock.createMock(Element.class);
  EasyMock.expect(n3.getNodeName()).andReturn(TAGNAME);

  NodeList nl = EasyMock.createMock(NodeList.class);
  EasyMock.expect(nl.getLength()).andReturn(3);
  EasyMock.expectLastCall().times(4);
  EasyMock.expect(nl.item(0)).andReturn(n1);
  EasyMock.expect(nl.item(0)).andReturn(n1);
  EasyMock.expect(nl.item(1)).andReturn(n2);
  EasyMock.expect(nl.item(2)).andReturn(n3);
  EasyMock.expect(nl.item(2)).andReturn(n3);

  Element el = EasyMock.createMock(Element.class);
  EasyMock.expect(el.getChildNodes()).andReturn(nl);

  EasyMock.replay(n1, n2, n3, nl, el);

  Assert.assertEquals(2, domUtils.getChildElementsByTagnameFromFirstLevel(el, TAGNAME).size());

  EasyMock.verify(n1, n2, n3, nl, el);
}</pre>
<p>Of course, you may have more advanced test method.<br />
Later on you realize, that you need to use the same method in another class. What would you normally do? Yes, move it to the some sort of utility class. But in that case, you would have this method static. And you would have to repeat the same mocking when testing the both classes. The better idea would be to create and interface <code>DOMUtils</code> with a method <code>List getChildElementsByTagnameFromFirstLevel(Element, String) </code>. Then, create implementation <code>DOMUtilsImpl</code>. And inject <code>DOMUtils</code> into needed classes. In this case you would need to mock only <code>DOMUtils</code>.</p>
]]></content:encoded>
			<wfw:commentRss>http://maksim.sorokin.dk/it/2010/03/12/hard-to-mock-objects/feed/</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
	</channel>
</rss>

