Why should we bother with unit testing?

| No Comments

When working on a big project, we have to code step by step and the higher level code is based on the low-level code, which means that if the lower level code is not reliable and you fix the bugs in such kind of level, it will still impact code at higher level. Yes, this is very annoying and that's the reason why we should bother using unit testing!

Unit test can give us confidence of what we've written and prove that our code is doing exactly what we think it should do. Some programmers never test their code until most part of the code has been written but by that time, it may be too late, because a project-wide code contains tons of functions and classes and it's hard to locate the positions of the bugs. Sometimes, things can turn to be even worse---we cannot determine what part of the code is working and what's not! I encounter such problems in the first iteration of csci3081w. In iteration 1, we had to add tons of tokenType, such as keywords, punctuations and variables, and created regular expression for every single tokenType. After that, we made a function called scanner, which would match each character in the input file and print out its tokenType to an output file. I didn't test my code until I finished , as a result, you can imagine how many errors I got! Recalling that time, I came to know the significant importance of unit testing.

Anyway, many people still have good excuse for not testing: time consuming--it's hard to set up and to learn testing frameworks, thus devoting valuable time to other tasks is reasonable. Unfortunately, CxxTest,the framework of unit test we are using in our class csci3081w, can counter this excuse. CxxTest has bunch of advantages-doesn't require member template functions,doesn't require any external libraries and doesn't require exception handling.In other words, CxxTest is designed to be as portable as possible.

The first time I use CxxTest was in the lab05 of csci3081. I have to include a header file at the beginning of our ".h file"(for example, "example.h")-- #include < cxxtest /TestSuite .h> (TestSuite is the base class of all tests). Then, I have to declare a class that inherits from TestSuite and in which we should put all the tests that the class is meant to perform. Another important thing I want to mention is that each method inside the class has to begin with "test" and has no return type or any parameters, so that the Python script can see it. There are also a number of assertions that can be used for quality assurance purposes. For example, we can use TS_ASSERT(4 * 4 > 4) to see whether 4*4 is greater than 4 or not and use TS_ASSERT_EQUALS(1+1,2) to see whether the first parameter is equal to the second one. After all these steps are done, the test file will be generated automatically! It's amazing to see that even if you change nothing in the related ".cpp file"(as the example above, this file should be "example.cpp"), all things that should be changed according to the ".h file"(example.h) are already there! My partner and I were both confused when we were doing this lab at the beginning and we even thought about changing the related ".cpp file" using our own source code! After that lab, I was still confused about "Cxxtest" and I asked my best friend Google, who said that after we create a child class of CxxTest::TestSuite, a Python script that actually writes the class that will perform the tests is run. Thus, the script does all the heavy lifting, keeping the developer form wasting hours of time trying to understand the arcane mechanics of the framework.

As far as I'm concerned, this simple idea describes the heart of unit testing: the single most effective technique to better coding!

never use source control before? Try it now!

| 2 Comments

Software project is developed by a team mostly, which means a tool that can make the team work efficient and enable team members to communicate in time when they are far away from each other is of great importance. In general, source control is such tool that makes the teamwork more convenient and more efficient and has some great properties to ensure the success of our project. A source control system is a place to store all the various revisions of the stuff you write while developing an application.

Source control offers tons of advantages to both teams and individuals:

First of all, it gives the team a project-wide undo button--this is of great importance. With knowing this property, my partner and I can try any code that we think it will work but are not sure of its correctness. All programmers encounter such problems: changing the code causes tons of errors, but for some reason they cannot change the code back to the original one. No exceptions for my partner and I. When we working on iteration 1, we wanted to add a pointer "next" in the "struct" of tokenType and use this pointer in our scanner.cpp file. But it turned out to be wrong and what made things much worse is that we cannot go back to the version without errors! Subversion saved our project---simply using the command "svn revert Scanner.h".

In addition, the version control system keeps a record of the changes made over time. Sometimes, I want to see changes that after my last commit--what part did my partner change? Simply using the "log" command, we can get all the information about certain file.

What's more, multiple developers can work on the same code at same time.Although when more than two people change the same part, a conflict will happen and team members have to change the code manually to solve the conflict. Most time, it works very well.

Beside advantages of source control system above, subversion has some other powerful feathers and its worth mention why you'd want to pick subversion.

From the paper "Pragmatic Version Control", I know that subversion is cheap to branch, tag and merging---it uses an efficient database model to branch and merge files, making these operations quick and painless, but in CVS, branching or labeling code requires more efforts--the server has to access and modify every file in the repository. And subversion is available for a wide variety of platforms, and most important, the server will run well on Windows--which is true cross-platform support.

There are some important things you have to know if you want to use subversion.

First, you have to use the "update" command frequently. The project is a team work and some of our teammates may work on the code when you are not. You want to make sure that you are working on the most up-to-date code every time you sit by your computer. For example, in iteration2, I forgot to update when I started, and when I wanted to commit, I was in trouble--I had to update first. Sadly, I found that my partner had already done the part I just worked on! I don't want you to get into such troubles.

Second, use "merge" properly. You and your partner can work on the same file at the same time, but if you want to commit your change but the svn says your local file is out of date, it means your partner have made some changes on this file after your last update. At this time, you need first to use "svn update" to update your local file to the most up-to-date file and then commit your changes using "svn commit -m "change file *.cpp" ". It works now! But if you and your partner work on the same part of the same file, you would not be so lucky. After you type the command "commit", you will see the conflicts between yours and your partner's. This time, you have to talk to your partner to decide which version you should use. That's what we learned and tried in labs and projects of 3081.I never use subversion before and It's so amazing. You definitely should use it!

Third, do use tags and branches. Sometimes, you want to see a previous version but the revision number is very hard to remember. That's why we give some versions that we are satisfied with a tag---name which is easy to remember. In the course 3081w, we have to do many iterations during the semester and my partner and I also put a tag on our first iteration. Anyway, tags should be read only.

"Source control is our first lag in programming", if you never use it before, you definitely should try it!

Challenges of working in teams

| No Comments

We got Iteration 1 done; but, it was challenging. With little skills in C++ my partner and I struggle throughout this project. Something we thought would be easy turned out to be difficult.

In the real world it is said a team must learn to cooperate, communicate and set standards in order to get a project done efficiently and effectively. In addition, it would also allow the team to divide and conquer the project. With this in mind, my partner and I divided the project into halves; I would be responsible for one half of project and my partner for the other half of the project. When I thought about this divided and conquer method it sounded so great due to the decrease in work load for the both of us. However, this wasn't the case because my partner and I didn't utilize team communication. As a result, we didn't set standards in which we would agree to use - such as having the same variables or place braced differently, thus led to challenges.

I believe the most challenging aspect from this project was when my partner and I came together to combine our project. For example, my partner and I named our variables differently and putted functions in a single file or separate files. To make thing worse we had our own preferences on how to write codes, thus led to disagreement. This was the result of not communicating with each other in the beginning. With this in mind, we then concluded together that we had to communicate if we wanted to get the project done. And so, my partner and I set up dates to come together to re-write our project so that it can be in a single format that both of us would agree and recognize. As a result of finally utilizing communication and collaboration, my partner and I were able to agree upon what functions to have, the naming of variables, the write up of the codes, what comments are needed, and how to put space to make the program more readable. In the end, the project was in format in which we both understand and there were no more disputes - even if we had a dispute we would solve it appropriately before things get out of hand. We also learned that we didn't need to use svn; however, now we know it's a good tool to use for future projects.

Although working in a team can be troublesome and challenging, it can also make a project much easier. Having a team allow the birth of many ideas to share because everyone think and solve problems in different ways. For example, if I were to work alone I will never know that there are other ways to solve a problem; but, if I work in a team I can learn and utilize the different ideas my partner have and improve my problem solving skills. Never the less, working in a team gives us the benefits- swapping our thoughts and learning from each other.

In contrast, one thing I notice when it comes to working alone is it can be rather difficult, especially when it comes to finding an error. This has happened to me so many times and it can be really painful because I think my program is perfect but I have to find where an error might be! Working with a partner will solve this situation very well. As I said above, everyone is different and everyone will picture a program differently. Consequently, the error you can't find will be fixed by others quickly. Maybe that is why different students ask different questions during a lecture.

Although working with a partner can make our life easier, sometimes we can mess it up for some reason. To keep all these benefit, we must always keep in mind -communication, good programming practice, comments and the use of tools.


What do you hope to learn?

| No Comments

As a student still in the lower division of computer science, I haven't done any big project development in
my life but after studying two years on campus, I have come to know the significance of good programming
practice -- effective comments, good programming style, consistent layout specifications, and defensive
codes, which will make teamwork easier and more efficient. I know for every programmer, what matters
most is technique but for every single student who wants to be an excellent programmer, how to work with
their team is as important as perfect technique. However, at this stage of software development, most have
to rely on teamwork. The world programmer is no longer synonymous with personal heroism. On one
hand, a programmer's complement of codes has to depend on others', on the other hand, his or her codes
will be accessed by others, which implies that the codes must provide reliable function, followed by a clear
expression of author's idea. As a result, standardized and defensive code is necessary. Such as how can
we name our variables and functions properly so that people read it can precisely know their functions,
whether the layout specification is consistent through the whole code, and whether the comment is
accurate and concise? Standardized and straightforward code will be more reusable, more maintainable,
and more convenient to extension. What's more, in a large-scale application software system, a complete
system consists of many fragments, which means the interaction between these fragments is a big deal. If
an error occurs, it maybe won't give feedback immediately, instead it will delay for some time after
transiting among certain functions. When things like this happen, it is very time consuming to find errors.
How can others use functions properly and avoid such problems as much as possible? The answer is
defensive code. In defensive code, there should be no input that can lead to an error. If unexpected data is
used, warnings will remind a programmer at once.
All of the above are what I learned from Csci1901--the most fundamental class for all students of computer
science. At the beginning of the project "railroad", I suffered. We had to build a railroad without knowing all
the specifications and wrote changeable code because the professor would give the "railroad" more
functions week by week. Obvious, having a partner could lessen one's burden, but working well with your
partner was not so easy -let her or him know how your functions worked, how to use it with appropriate
variables, and never get errors when bad data is inputted. Once you mastered the skill to operate with your
partner, it would be done in the twinkling of an eye. I enjoy the great benefit of this class very much--
effective comments, good program style, consistent layout specifications, and defensive codes should
always be use.
In addition, at the end of this course csci3081w, we will learn many useful tools and techniques, but what
attracts me most is debugging because for all programmers even the most talented ones, error is
unavoidable. I think every programmer suffers when they can't find the error even if they think the code is
perfect and it should give the right result. But unfortunately, things do not turn out as one wish. When we
check the code until going mad but still can't find an error and once click on the "execute", it crashes, a
debugger is our last hope. Maybe someone will say it can only help us to find some stupid hidden logic
errors but is of no use to our program development. It's true, but we can't depend on machine to do all our
duties. However, although I'm not skilled at it, but I know the debugger of visual C++ has set breakpoint,
trace the call stack, and disassembly debugging. Even the most common function breakpoint is really
powerful. We can set breakpoint everywhere we want and then execute the program step by step until we
find the problem.
To sum up, if you let me choose one that I want to learn most, it is definitely debugging and I will keep the
good programming practice in my further programming life.
Yujing Sun
4436779

Find recent content on the main index or look in the archives to find all content.

Recent Comments

  • xuxxx728: We usually email to each other what we have committed. read more
  • xuxxx728: We usually email to each other what we have committed. read more

Categories

Pages

Powered by Movable Type 4.31-en