Hello everyone,
Well, as part of my senior design class for computer science, we are assigned teams of four and each team gets a different project. Our project looks like it will involve a lot of JavaScript. This is good, because I am a fan of JavaScript and don't know it nearly as much as I would like. Also, I'm sick of every class project being in Java (not because I hate Java, just because I'd like to see some variety). Anyway, we're going to be doing a few small web applications that will be using a Java backend (!). Luckily, most of the interesting stuff will be client side.
I took it upon myself to set up everyone's favorite tools like Jenkins. I also had to search out a bug tracker to install. I haven't installed a bug tracker before and I have to say, some of them are a real pain to install and have a lot of dependencies. So after trying out some popular ones and disliking the setup process, I went with one called YouTrack.
I like YouTrack because installing it consists of me deploying it on Tomcat (after the install program), and I'm a big fan of doing as little as possible. I haven't worked with it that much yet but so far it seems simple enough. So if you're looking for a bug tracker with a simple setup and running a windows server, go ahead and give it a try.
(disclaimer: I don't work for them!)
See you next time.
Monday, January 23, 2012
Thursday, January 19, 2012
Rely on your (well written) tests when adding new features
Hi everyone!
Well, I found some time to make a post here. On the ASP .Net project we're working on, things are going pretty well (although they have slowed a bit -- working on getting back into it). Still don't have my dev machine though.
Anyway, our previous work over the past two months has been mostly bug fixing, but we've recently implemented an actual new feature. The feature in question required some pretty substantial modification of various parts of the site and so the potential for breaking things was there.
Luckily, both our unit test suite and functional tests have grown pretty substantially and so there is a lot of coverage to ensure things don't break. In fact, the feature in question affects areas that happen to be heavily tested, so we can prevent regressions that way.
But it's not just about having test coverage of the code you're modifying -- you have to treat your test code right. That is to say, the test code is not "just test code" and it should be held to certain quality standards like your production code. We've spent a good chunk of our time establishing a test architecture when we could spend that time cranking out more badly written, fragile, hard to maintain tests.
Instead, we've taken the time to isolate potential changing parts of the code (such as element locaters) and build an abstraction layer on top of the Selenium API specific to our project. This makes the tests easier to maintain and less susceptible to UI changes. Another nice benefit is that it's reduced the time it takes to write functional tests like this substantially. Most of the actual Selenium code has already been written, and writing a test means creating different page objects and calling their methods.
When we do add to the page objects, it's usually a small amount of code and just means we'll be reusing it later.
So, the moral of this story: treat your tests right and you will benefit from it (we certainly have).
See you next time!
Well, I found some time to make a post here. On the ASP .Net project we're working on, things are going pretty well (although they have slowed a bit -- working on getting back into it). Still don't have my dev machine though.
Anyway, our previous work over the past two months has been mostly bug fixing, but we've recently implemented an actual new feature. The feature in question required some pretty substantial modification of various parts of the site and so the potential for breaking things was there.
Luckily, both our unit test suite and functional tests have grown pretty substantially and so there is a lot of coverage to ensure things don't break. In fact, the feature in question affects areas that happen to be heavily tested, so we can prevent regressions that way.
But it's not just about having test coverage of the code you're modifying -- you have to treat your test code right. That is to say, the test code is not "just test code" and it should be held to certain quality standards like your production code. We've spent a good chunk of our time establishing a test architecture when we could spend that time cranking out more badly written, fragile, hard to maintain tests.
Instead, we've taken the time to isolate potential changing parts of the code (such as element locaters) and build an abstraction layer on top of the Selenium API specific to our project. This makes the tests easier to maintain and less susceptible to UI changes. Another nice benefit is that it's reduced the time it takes to write functional tests like this substantially. Most of the actual Selenium code has already been written, and writing a test means creating different page objects and calling their methods.
When we do add to the page objects, it's usually a small amount of code and just means we'll be reusing it later.
So, the moral of this story: treat your tests right and you will benefit from it (we certainly have).
See you next time!
Monday, January 9, 2012
Back in school again...
Hi everyone.
Well, I'm back in school again about to start my last semester of university (hopefully). This is my 5th year and I'm trying to wrap up everything for computer science and chemistry. Chemistry is proving to be the more annoying one to account for.
Anyway, there won't be too many updates in these first couple weeks until I get into the usual routine, and I also don't have my dev machine at the moment. Instead I'm using my old crusty laptop. Ah well.
And finally for reference, here's some of what I'm hoping to get into more this year:
Well, I'm back in school again about to start my last semester of university (hopefully). This is my 5th year and I'm trying to wrap up everything for computer science and chemistry. Chemistry is proving to be the more annoying one to account for.
Anyway, there won't be too many updates in these first couple weeks until I get into the usual routine, and I also don't have my dev machine at the moment. Instead I'm using my old crusty laptop. Ah well.
And finally for reference, here's some of what I'm hoping to get into more this year:
- More JavaScript, both client and server side.
- Clojure, haven't devoted as much time as I wanted.
- Continue ASP .Net development
- Use some formal MVC frameworks for Java development
- Finish reading SICP (!)
Subscribe to:
Posts (Atom)