MarkUs Blog

MarkUs Developers Blog About Their Project

Sharing some newbie’s experience, =P

with 2 comments

In last week, I fixed the bug #570. Although this bug is not a difficult one, I do learn a lot in the process fixing it. I would like to share some experience of it. My route may not be as efficient as yours, please feel free to advice a better way. I need you guys’ suggestion to improve my skills,=P.

Firstly, I used the following way to find the place to start. For example, in the #570, the problem is the string not being stripped. Without much knowledge about the project structure, I just ran the project, opened the firefox with firebug running, and then find the string name “user_name” in the table on the page of adding user. After I got the string name I made a search in the project of “user_name” which returned quite a lot of results. Then I started to browse those results to find target methods like “create”, ”add”, “update” etc. I did find these methods in “/controllers/students_controller.rb” which use the parameter params[:user] to create the new student records.

At first glance this seemed to be the place to modify the string, and I modified the string here, which did work when I did some manual tests. However, I noticed that there are at least 3 controllers of “student”, ”ta” and “admin” that use very similar methods. If I applied the rough ideas I will need to modify at least 3 places that will potentially bring difficulty of maintenance in future. Then I started to think about finding the original place of this user object. Some places that I suppose things like the string validation would happen. When I noticed that there is a User class that are inherited by “student”, ”ta” and “admin”, I knew this is the right place to do the job.

However, I didn’t know how to do this due to my lack of knowledge of Rails. Well, here I learned how to save your time by asking your team members who know the projects well and are willing to help,=). Just asked a quick question to Mike and he pointed out that there are some callbacks in ActiveRecord that we can use to validate the variables at different states. Then I started to search the web and figured out how to use it. A new method was added to User class to trip all the input strings. At this point I have already solved half of the problem. It was exciting to me!

The next step will be adding test cases for this new method. Again, communication is really important and I learned how to write the test cases from Mike. Here are some rough steps I did for my tests:

  1. Make sure you have no error and no failure before your modification to the project.
  2. Find the unit test under test/unit. There is usually a name matching from the test case to the tested class. For example I found the “user_test.rb” test “user.rb”.
  3. I have no idea how to write the test cases at first. I talked to Mike and also took a look at existing test cases. As suggested, we shall use shoulda to test because it is better for reading. For me, I didn’t really search tutorials of shoulda on the web. I just found some existing codes in our project and figured out the basic structure is like:

context “some one” do

  1. setup do
  2. end
  3. should “do something” do
  4. assert something
  5. end
  6. end

Basically “setup do” is the place to put the setup of your test values. And “should” is the place to add the function you perform like user. save, and tests you add like assert, assert_nil, assert_equal. You can add multiple shoulds within a context.

When your run the test by typing ruby -Itest test/unit/sometest.rb, it will give the result like “some one do something <false> is not true “when your test case fails.

4. I suggest after you pass the single test that you modified, run a full tests (rake test:units) to make sure you pass all the rest tests as well.

Check our last irc meeting log, you will find some useful tips about testing.

Above are some thoughts I come up with my experience of solving #570. I hope it suggest some useful points. If you get confused at some points, please let me know. I would try to explain. And I am also willing to hear  from you guys,=).

Written by Brian Xu

January 24th, 2010 at 8:34 pm

2 Responses to 'Sharing some newbie’s experience, =P'

Subscribe to comments with RSS or TrackBack to 'Sharing some newbie’s experience, =P'.

  1. Brian:

    It’s really refreshing to hear what it’s like working on MarkUs for the first time. I remember being pretty confused and frustrated with MarkUs (called OLM when I started working on it back in 2008). If you’re interested, here are some of my first blog posts detailing a super frustrating problem that had me stumped for about a week:

    Part I: http://blog.markusproject.org/?p=138
    Part II: http://blog.markusproject.org/?p=142
    Part III: http://blog.markusproject.org/?p=144
    Part IV: http://blog.markusproject.org/?p=146

    Reading this, your thought process is sound. Diving into a new codebase is like being dropped into the middle of a big forest without a map or compass. But it looks like you’re figuring out the terrain just fine! 🙂

    And like you said – communication is super important. Very very true.

    Great work on the post!

    -Mike

    m_conley

    24 Jan 10 at 9:50 pm

  2. Great post Brian! Just keep asking questions :-). There’s always somebody to help out.

    Severin

    25 Jan 10 at 3:27 pm

Leave a Reply