I realize I haven't blogged about Neptune for a while, but I actually have been making progress on it. I have just been finding a hard time making time to blog. Hopefully I will get better about that.
What I want to cover today is the process of writing automated tests in Neptune to which you can then write your code.
Fusion Authority recently ran an article called What's Hot? What's Not? Where Do We Go From Here? subtitled "What technologies, other than ColdFusion, should a developer know?". Mike Henke followed up the theme with a post called "What's Hot & Where do we go from here?".
I'm pretty sure I don't have the insight that other people have who have already written on the subject. But it seemed like a fun exercise, so I thought I would toss in my two cents with:
I'm not sure what technologies you should learn, but here are the ones that I am learning:
In programming, discussions often come up about which approach to solving a problem is faster. Although I think these discussions often miss the point (as other decision factors often trump execution speed), they are still often informative.
I have had a few occassions recently where I wanted to answer these questions myself. It seemed tedious to continue to write code to test that out, so I decided to write a generic "Code Timer" to run code and test for execution times.
We recently started working on a project that, while relatively small now, has the stated potential to grow into a rather large and complex system in the near future. On a few big projects that I have now, I have regretted not having used TDD on them from the beginning (having learned TDD only well after those projects were already under way).
This seemed a perfect opportunity to do now what I wished I had done earlier on those projects.
Hopefully some dear readers can help me out with my current quandary.
I have several components that I use on nearly every site that I develop. By using them, I save untold hours of programming and therefore provide cheaper results for my clients. At the same time, I am using solutions that have been tried and proven rather than developing from scratch every time.
There is, of course, a catch to all of this.
In our last user's group meeting, we had a round table discussion about testing. I said that I would put together a simple example of a unit test.
Since I have been using CFUnit so far (MXUnit looks attractive as well though), that is what I will use for my example. The principles should work the same for any common testing framework.
We have been working to enable access to our data via ODBC and/or MS Access - a project more complicated than expected. While we were working on this, I went to cf.Objective.
Among the very good presentations I attended was one called "Test Driven Development" by Paul Kenney. I had attended a few online presentations about TDD before and read a few articles as well. I always came away thinking that I should try that out "some day", but also feeling like I didn't quite grasp the concept fully (I did not grok TDD).
