My current rails project is using Blue Ridge and the tool set it bundles together (Rhino, env.js, Screw.Unit, and Smoke) to write test driven JavaScript. The ability to write tests of my JavaScript, in JavaScript, as efficiently as I can test other languages has forced me to rethink how I structure my work and I’m writing better code because of it.
There are a couple of different options for JS testing available at this point but Blue Ridge’s plugin is the first I have seen which made writing test driven code as easy as I have come to expect while still providing all the functionality I need. In particular;
- Running my tests in a browser is fast. Refreshing fixture pages to rerun tests is dramatically more efficient than waiting for selenium tests to cycle.
- I can debug my tests as they run against their fixtures pages and inspect or manipulate the DOM at any point.
- I have mock and fake objects available to test behavior and stub out dependencies.
- My JS tests run in continuous integration, just like all the other tests.
By writing fixtures pages and tests first I am immediately using all of my code in two locations and running it against slightly different DOMs. That has pushed me to encapsulate most of my code as jQuery plugins and think carefully about how much I depend on the page’s structure. I end up with terse selectors instead of using whatever attributes are readily available and a clear configuration point for my page’s behavior as I chain together plugin calls in $(document).ready().
We’d like to see what other developers have done and share what we have learned so far so Carbon Five is hosting an open discussion of JavaScript testing in our office this week.
Topic: Javascript Testing
When: Tuesday Nov 17
6pm: arrive/network
6:30 – 8 presentation and discussion
Where: Carbon Five office: 171 2nd Street, 4th Floor
Please RSVP if you would like to attend.
Published by
alex on
November 12, 2009 in
Java.
Both Carbon Five and my ISP have moved email management over to Gmail. While this has been a net improvement for me as an end user, it’s made it a bit more difficult to configure my applications to send outgoing mail. It isn’t hard to find examples online that explain how to configure Spring’s JavaMailSender to work with Gmail. But none of the examples I’ve found provide a configuration that can be switched between Gmail and an open SMTP server with a few reasonable external properties (an important feature in an application that needs to be deployed in varied environments). What’s worse, the configurations tend to differ with no rational provided for the necessary parameters. So I spent some time with the source and a debugger and came up with a simplified solution:
<bean id="mailSender" class="org.springframework.mail.javamail.JavaMailSenderImpl">
<property name="defaultEncoding" value="UTF-8"/>
<property name="host" value="${mail.host}"/>
<property name="port" value="${mail.port}"/>
<property name="protocol" value="${mail.protocol}"/>
<property name="username" value="${mail.username}"/>
<property name="password" value="${mail.password}"/>
<property name="javaMailProperties">
<props>
<prop key="mail.debug">${mail.debug}</prop>
<prop key="mail.${mail.protocol}.auth">${mail.smtp-auth}</prop>
</props>
</property>
</bean>The properties for an open server look something like this:
mail.host = localhost
mail.port = 25
mail.protocol = smtp
mail.smtp-auth = false
mail.username =
mail.password =
mail.debug = false
And the properties for gmail look something like this:
mail.host = smtp.gmail.com
mail.port = 465
mail.protocol = smtps
mail.smtp-auth = true
mail.username = my.email@address.com
mail.password = mypassword
mail.debug = true
The host, port, username, password and debug properties should be obvious. The key is to change the protocol between ‘smtp’ and ‘smpts’. The only real difference between smtp and smtps is that the later causes JavaMail’s SMTPTransport object to open an SSL socket to the server. Gmail only accepts SSL connections on port 465. After figuring this out, I was glad to see that Gmail was accepting my connections, but immediately frustrated to find that JavaMail was no longer attempting to authenticate before sending mail. The trick is that JavaMail checks its transport related parameters under ‘mail.[protocol].[parameter]‘. This appears to be an entirely undocumented feature of JavaMail. Fortunately, we can substitute the protocol name into the parameter key as well, so our auth parameter still works with either ‘smtp’ or ‘smtps’.
