Re: Unit testing mixins
Hi Thiago, > Well, the idea of automated testing is to write the test before the tested > feature or at least just after you implemented the feature. > This quick outdating is quite strange: it seems the team is not writing tests > in a > more safe manner or the markup is changing very fast. Am I right? Okay you got me... We rely mostly on our unit tests and have continuous integration only for those, so the Selenium test was only used for black box testing at the end of our release cycle, but was not part of the test suite so was kind of an afterthought. The code changed so fast that it defeated the purpose of having the test, sop we abandoned it. We are under resourced and have tight deadlines, so we have limited time to write both unit and integration tests... but you tend to pay for sloppiness down the line so this is why I mention I would have to have a rethink about that, as unit tests are great but they are not always enough. Abandoning the Selenium test means we no longer test Pages, Mixins or JavaScript, but I plan to change this soon. One thing we have done right though is ensuring very clean code separation, so tests are easy to write without many changes. I will first look into Inge's suggestion, and if we are not covering enough the we may consider a few smaller targeted Selenium tests rather than one larger one as we did in the past. Cheers, Peter - Original Message - From: "Thiago H. de Paula Figueiredo" To: "Tapestry users" , "P Stavrinides" Sent: Monday, 20 June, 2011 14:52:06 GMT +02:00 Athens, Beirut, Bucharest, Istanbul Subject: Re: Unit testing mixins On Mon, 20 Jun 2011 04:22:27 -0300, wrote: > Hi Inge, Thiago, Hi! > Firstly, Thanks guys for your replies! > I was aware of Jasmine, but not JsTestDriver... together they look very > promising (powerful) for unit tests. I think I will give them a go. You're welcome! > As for Selenium, we had used it in the past for integration testing, but > we wrote only one larger scale test with broad coverage... It was pretty > good as well, but we found the test got outdated almost as quick as we > could write it. Well, the idea of automated testing is to write the test before the tested feature or at least just after you implemented the feature. This quick outdating is quite strange: it seems the team is not writing tests in a more safe manner or the markup is changing very fast. Am I right? I work on projects which forbid commits without tests, almost all the tests are Selenium ones and we don't have this quick outdating you're experiencing. We do need to fix some tests after the markup it's based on changes, but this doesn't happen frequently. > After a time we were not maintaining it because it was quite time > consuming to do. Worst case I will revisit Selenium and have a rethink > about better maintenance this time. If your tests are failing, the recommended approach is to stop development and fix bugs (code or tests) until all tests pass. -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Unit testing mixins
Hi The best way to learn testing tapestry is by reading the tests present in the source code. Also, I learned a lot from the test written in chenillekit. Hope it helps regards Taha On Mon, Jun 20, 2011 at 5:22 PM, Thiago H. de Paula Figueiredo < thiag...@gmail.com> wrote: > On Mon, 20 Jun 2011 04:22:27 -0300, wrote: > > Hi Inge, Thiago, >> > > Hi! > > > Firstly, Thanks guys for your replies! >> I was aware of Jasmine, but not JsTestDriver... together they look very >> promising (powerful) for unit tests. I think I will give them a go. >> > > You're welcome! > > > As for Selenium, we had used it in the past for integration testing, but >> we wrote only one larger scale test with broad coverage... It was pretty >> good as well, but we found the test got outdated almost as quick as we could >> write it. >> > > Well, the idea of automated testing is to write the test before the tested > feature or at least just after you implemented the feature. This quick > outdating is quite strange: it seems the team is not writing tests in a more > safe manner or the markup is changing very fast. Am I right? I work on > projects which forbid commits without tests, almost all the tests are > Selenium ones and we don't have this quick outdating you're experiencing. We > do need to fix some tests after the markup it's based on changes, but this > doesn't happen frequently. > > > After a time we were not maintaining it because it was quite time >> consuming to do. Worst case I will revisit Selenium and have a rethink about >> better maintenance this time. >> > > If your tests are failing, the recommended approach is to stop development > and fix bugs (code or tests) until all tests pass. > > -- > Thiago H. de Paula Figueiredo > Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, > and instructor > Owner, Ars Machina Tecnologia da Informação Ltda. > http://www.arsmachina.com.br > > --**--**- > To unsubscribe, e-mail: > users-unsubscribe@tapestry.**apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
Re: Unit testing mixins
On Mon, 20 Jun 2011 04:22:27 -0300, wrote: Hi Inge, Thiago, Hi! Firstly, Thanks guys for your replies! I was aware of Jasmine, but not JsTestDriver... together they look very promising (powerful) for unit tests. I think I will give them a go. You're welcome! As for Selenium, we had used it in the past for integration testing, but we wrote only one larger scale test with broad coverage... It was pretty good as well, but we found the test got outdated almost as quick as we could write it. Well, the idea of automated testing is to write the test before the tested feature or at least just after you implemented the feature. This quick outdating is quite strange: it seems the team is not writing tests in a more safe manner or the markup is changing very fast. Am I right? I work on projects which forbid commits without tests, almost all the tests are Selenium ones and we don't have this quick outdating you're experiencing. We do need to fix some tests after the markup it's based on changes, but this doesn't happen frequently. After a time we were not maintaining it because it was quite time consuming to do. Worst case I will revisit Selenium and have a rethink about better maintenance this time. If your tests are failing, the recommended approach is to stop development and fix bugs (code or tests) until all tests pass. -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Unit testing mixins
Hi Inge, Thiago, Firstly, Thanks guys for your replies! I was aware of Jasmine, but not JsTestDriver... together they look very promising (powerful) for unit tests. I think I will give them a go. As for Selenium, we had used it in the past for integration testing, but we wrote only one larger scale test with broad coverage... It was pretty good as well, but we found the test got outdated almost as quick as we could write it. After a time we were not maintaining it because it was quite time consuming to do. Worst case I will revisit Selenium and have a rethink about better maintenance this time. Thanks again! Peter - Original Message - From: "Inge Solvoll" To: "Tapestry users" Sent: Friday, 17 June, 2011 13:11:12 GMT +02:00 Athens, Beirut, Bucharest, Istanbul Subject: Re: Unit testing mixins As long as your JS code is clean with low coupling, I think the best solution is to do pure JS testing. I've done a lot of this. Used Jasmine BDD for testing the javascript code. Very nice testing framework that works both in the browser and headless, from Jenkins/Hudson. http://pivotal.github.com/jasmine/ http://cjohansen.no/en/javascript/test_driven_javascript_done_right http://skaug.no/ingvald/2010/10/javascript-unit-testing.html On Thu, Jun 16, 2011 at 4:09 PM, Thiago H. de Paula Figueiredo < thiag...@gmail.com> wrote: > On Thu, 16 Jun 2011 08:43:28 -0300, wrote: > > Hi all, >> > > Hi! > > > We are converting most of our JavaScript code in our Tapestry applications >> into mixins, and I was wandering if anyone can recommend a testing framework >> / methodology for unit testing these mixins. >> > > I use JUnit (it could be TestNG or any other similar framework) + Selenium. > I create a page using the given mixin and test it. This isn't an unit test: > it's an integration one, but it does the work, specially when there's > JavaScript involved. > > -- > Thiago H. de Paula Figueiredo > Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, > and instructor > Owner, Ars Machina Tecnologia da Informação Ltda. > http://www.arsmachina.com.br > > > --**--**- > To unsubscribe, e-mail: > users-unsubscribe@tapestry.**apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Unit testing mixins
As long as your JS code is clean with low coupling, I think the best solution is to do pure JS testing. I've done a lot of this. Used Jasmine BDD for testing the javascript code. Very nice testing framework that works both in the browser and headless, from Jenkins/Hudson. http://pivotal.github.com/jasmine/ http://cjohansen.no/en/javascript/test_driven_javascript_done_right http://skaug.no/ingvald/2010/10/javascript-unit-testing.html On Thu, Jun 16, 2011 at 4:09 PM, Thiago H. de Paula Figueiredo < thiag...@gmail.com> wrote: > On Thu, 16 Jun 2011 08:43:28 -0300, wrote: > > Hi all, >> > > Hi! > > > We are converting most of our JavaScript code in our Tapestry applications >> into mixins, and I was wandering if anyone can recommend a testing framework >> / methodology for unit testing these mixins. >> > > I use JUnit (it could be TestNG or any other similar framework) + Selenium. > I create a page using the given mixin and test it. This isn't an unit test: > it's an integration one, but it does the work, specially when there's > JavaScript involved. > > -- > Thiago H. de Paula Figueiredo > Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, > and instructor > Owner, Ars Machina Tecnologia da Informação Ltda. > http://www.arsmachina.com.br > > > --**--**- > To unsubscribe, e-mail: > users-unsubscribe@tapestry.**apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
Re: Unit testing mixins
On Thu, 16 Jun 2011 08:43:28 -0300, wrote: Hi all, Hi! We are converting most of our JavaScript code in our Tapestry applications into mixins, and I was wandering if anyone can recommend a testing framework / methodology for unit testing these mixins. I use JUnit (it could be TestNG or any other similar framework) + Selenium. I create a page using the given mixin and test it. This isn't an unit test: it's an integration one, but it does the work, specially when there's JavaScript involved. -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Unit testing mixins
Hi all, We are converting most of our JavaScript code in our Tapestry applications into mixins, and I was wandering if anyone can recommend a testing framework / methodology for unit testing these mixins. We have only just started to think about a solution, but we currently use JUnit 4 and Testify to test IoC services, so we are familiar with these... an ideal solution would play nice with these frameworks. I am also aware of the @ForComponents annotation in Testify for testing components, to be honest I haven't used it much and couldn't found any examples of using it to test mixins... can it? If there isn't anything already integrated with Tapestry's mixin architecture, then I guess I could test only the JavaScript code. Since we always try to use external .js files with a mixins, we do have have the required separation. Would love to know what others are doing... any thoughts? Kind regards, Peter - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
