Comments on: Middleware integration testing with JUnit, Maven and VMware, part 1 (of 3) http://blog.xebia.com/2009/12/07/middleware-integration-testing-with-junit-maven-and-vmware-part-1/ Software development done right! Wed, 08 Feb 2012 14:41:38 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: cuppa-joe http://blog.xebia.com/2009/12/07/middleware-integration-testing-with-junit-maven-and-vmware-part-1/#comment-93986 cuppa-joe Sat, 23 Jan 2010 18:15:56 +0000 http://blog.xebia.com/?p=3825#comment-93986 "Without knowing the code under test, these sound to me as typical signs of code smells. Why do you need to debug often?" Suggesting that a system does not need to be debuggable is a typical sign of developer smells. “Without knowing the code under test, these sound to me as typical signs of code smells. Why do you need to debug often?”

Suggesting that a system does not need to be debuggable is a typical sign of developer smells.

]]> By: Vincent Partington http://blog.xebia.com/2009/12/07/middleware-integration-testing-with-junit-maven-and-vmware-part-1/#comment-93421 Vincent Partington Tue, 08 Dec 2009 09:57:25 +0000 http://blog.xebia.com/?p=3825#comment-93421 <b>@Lars:</b> Thanks for your comments. You make some good points! I'll reply to them one by one. 1a. To start from the end of your point: I guess you could say that these tests are actually our unit tests. They are tests for what it is basically about 20 lines of Python code and some Java glue. It's just that they require a <em>very big</em> test fixture (in the non-Fitnesse meaning of the word ;-)) and that they integrate with the middleware. These tests are not the integration tests for our product itself but tests for the integration with the middleware. And because JUnit provides a nice way to run these steps in isolation we use JUnit to develop and therefore debug our Python/Java code. Using Fitnesse for that was just too painful (what with the remote attaching of the debugger and all). 1b. To set up the actual integration test for our product we'd actually want to test from our Flex UI (or the command line interface) straight to the middleware. Most of our product integration woes had to do with the BlazeDS or Hessian serialization used by the Flex UI and the CLI respectively. For the Flex UI we've looked into all kinds of different Flex UI testing frameworks about a year ago but found none to be working very well. Recently I've seen good things from <a href="http://code.google.com/p/flexmonkey/" rel="nofollow">FlexMonkey</a> so we'll try again soon. 2. The product will indeed be used by sysadmins. And since they are usually not that versed in Java we chose Fitnesse in the first place. But since we are building a standard product and there are no non-Java-savvy (Java-unsavvy) people on our team, it really did not fit us that well. If this were a bespoke project where non-Java developers were more involved in the daily development of our product Fitnesse would certainly make sense. BTW, I've changed the title of this blog (and the URL) to reflect the kind of integration this blog is talking about. There was a typo in the old title anyway. ;-) @Lars: Thanks for your comments. You make some good points! I’ll reply to them one by one.

1a. To start from the end of your point: I guess you could say that these tests are actually our unit tests. They are tests for what it is basically about 20 lines of Python code and some Java glue. It’s just that they require a very big test fixture (in the non-Fitnesse meaning of the word ;-) ) and that they integrate with the middleware. These tests are not the integration tests for our product itself but tests for the integration with the middleware. And because JUnit provides a nice way to run these steps in isolation we use JUnit to develop and therefore debug our Python/Java code. Using Fitnesse for that was just too painful (what with the remote attaching of the debugger and all).

1b. To set up the actual integration test for our product we’d actually want to test from our Flex UI (or the command line interface) straight to the middleware. Most of our product integration woes had to do with the BlazeDS or Hessian serialization used by the Flex UI and the CLI respectively. For the Flex UI we’ve looked into all kinds of different Flex UI testing frameworks about a year ago but found none to be working very well. Recently I’ve seen good things from FlexMonkey so we’ll try again soon.

2. The product will indeed be used by sysadmins. And since they are usually not that versed in Java we chose Fitnesse in the first place. But since we are building a standard product and there are no non-Java-savvy (Java-unsavvy) people on our team, it really did not fit us that well. If this were a bespoke project where non-Java developers were more involved in the daily development of our product Fitnesse would certainly make sense.

BTW, I’ve changed the title of this blog (and the URL) to reflect the kind of integration this blog is talking about. There was a typo in the old title anyway. ;-)

]]> By: Lars Vonk http://blog.xebia.com/2009/12/07/middleware-integration-testing-with-junit-maven-and-vmware-part-1/#comment-93417 Lars Vonk Mon, 07 Dec 2009 20:57:55 +0000 http://blog.xebia.com/?p=3825#comment-93417 Hi Vincent, You should indeed always use tools the team is most comfortable with. Mix and match. Use the best tools for the job. When something is really an unit test and if it is easier to write with junit you should of course use that. I have some remarks/questions though about your reasoning: 1. You say "If we wanted to test just a single step, we had to make a deployment scenario that used that step just to be able to test it." and "And while debugging code under test in Fitnesse is complicated enough, debugging Fixture is even harder". Without knowing the code under test, these sound to me as typical signs of code smells. Why do you need to debug often? Why is a single step hard to test? To need to debug is often a smell of lack of (smaller) unit tests. 2. "While it might be a very nice to tool do user acceptance testing and allow end users to write (or at least understand) tests, the technical nature of our product already ensured that we would not have tests for non-technical end-users". As I understand the product it will be used by sysadmins right? Do they understand/read/extend the junit tests? I hardly believe that. Do not underestimate the power of readable tests. It is not only providing them readable tests, but you also provide the ability to add tests. This is very good for building trust in an application (and team). Regards, Lars Hi Vincent,

You should indeed always use tools the team is most comfortable with. Mix and match. Use the best tools for the job. When something is really an unit test and if it is easier to write with junit you should of course use that.

I have some remarks/questions though about your reasoning:

1. You say “If we wanted to test just a single step, we had to make a deployment scenario that used that step just to be able to test it.” and “And while debugging code under test in Fitnesse is complicated enough, debugging Fixture is even harder”. Without knowing the code under test, these sound to me as typical signs of code smells. Why do you need to debug often? Why is a single step hard to test? To need to debug is often a smell of lack of (smaller) unit tests.

2. “While it might be a very nice to tool do user acceptance testing and allow end users to write (or at least understand) tests, the technical nature of our product already ensured that we would not have tests for non-technical end-users”.
As I understand the product it will be used by sysadmins right? Do they understand/read/extend the junit tests? I hardly believe that. Do not underestimate the power of readable tests. It is not only providing them readable tests, but you also provide the ability to add tests. This is very good for building trust in an application (and team).

Regards, Lars

]]>