For our software engineering class we have been assigned the task of creating a list of 10 question that students should be able to answer quickly as a practice for the midterm. I created my questions trying to address mostly issues of sofware engineering and effective communication and not general programming.
Well here is goes...Good Luck!
1.Name three different kinds of that you can perform using junit and give an example of each.
Answer:
Acceptance, Behavioral, Unit
2.What is the difference between white box and black box testing?
Answer:
Black box testing is testing a program without knowledge of its internal working. Providing input only to confirm proper output and not what happens in between.
White box testing is testing with the ability to check the functionality of the code on the inside Having knowledge/access to the source code.
3.Name 2 benefits and 1 negative factor of distributed versus centralized as it pertains to subversion.
Answer:
Distributed systems have greater speed performing most task. Doesn't have a single point of failure. Has the flaw of not having a "czar" to constantly oversee code progress and maintain code.
4.What is the different between pmd and findbugs?
Answer:
pmd checks source code and findbugs looks in the compiled byte code.
5.What are 3 things we used checkstyle to check for in this course?
Answer:
Spacing
JavaDoc
That the open bracket was on the same line as the start of a method/class/etc..
6.Why is a professional persona important?
Answer:
It allows potential employers and others to gain knowledge of our interest and skills pass what a one page resume is able to showcase.
7.What are the three prime directives we used in this course and why are they useful to software engineers?
Answer:
That the software is able to perform a useful task. This is tested by an end user and not the developer.
That the software has proper documentation that it can be installed and used without much input from the developer. This is tested by an external installer and not the developer.
That the software has proper documentation and general good programming so it can be understood, used and modified by another developer. This is tested by external developer.
8.List 3 reasons why it's good to be a single-tasker versus a multi-tasker.
Answer:
Accomplish task faster.
Reduce the amount of errors you incur performing a task.
Reduces stress.
9.list 2 reasons why is it good to document code properly?
Answer:
To make code more readable during development and after development.
Make code understandable by other developers.
10.Give an example of a good post if you are trying to get help for a coding issue online?
Answer:
Uninitialized object error at the start of a loop.
I am receiving an uninitialized object error when running the code below.
***code directly starting the loop and then going through loop at least 2 lines below error***
Basically showcase the code thats generating the error and providing a copy of exact error doesn't hurt.
Monday, October 19, 2009
Wednesday, October 14, 2009
To Google or not to ...
For the past few weeks, I have been working on my robocode Robot MikeTerry. But now I want to share my code so that other developers can edit MikeTerry and make it even better. By getting familiar with Google Project and SVN client.
The only part in my conquest to put MikeTerry out there that I was unable to succeed in was to add codesite-noreply@google.com as a discussion list member, but otherwise I didn't encounter any problems.
I have learned that Google provides great features for developers. By creating Google Projects and Discussion Boards, the simplicity of having another developer look at your code became a world wide affair.
Here is a link to my discussion group
The only part in my conquest to put MikeTerry out there that I was unable to succeed in was to add codesite-noreply@google.com as a discussion list member, but otherwise I didn't encounter any problems.
I have learned that Google provides great features for developers. By creating Google Projects and Discussion Boards, the simplicity of having another developer look at your code became a world wide affair.
Here is a link to my discussion group
Wednesday, October 7, 2009
Testing: Being on point.
During the past week, I had MikeTerry (please see previous posting) doing tests to make sure he knew what he was suppose to do. MikeTerry went thru six tests case, which he successfully passed with flying colors. Here are the tests and results of this past week testing phase.
Acceptance tests are to be making sure that MikeTerry can consistently beat one or more of the sample robots that I have been using in previous assignments.
Test 1- MikeTerry VS. Fire: MikeTerry constantly won against this robot.
Test 2 - MikeTerry VS. Crazy: MikeTerry constantly won against this robot.
Behavioral tests make sure that MikeTerry that his movements and strategies are on point.
Test 3 - Clockwise path: As part of MikeTerry’s strategy, he needs to move clockwise; by doing this test I was able to see that MikeTerry always used a clockwise path without making any changes in his coding.
Test 4 - All 4 corners: One of the other strategies is to move to all four corners, which MikeTerry did successfully without any major changes in his coding.
Test 5 - Out of the center: I wanted for MikeTerry to stay within the outter wall radius and he did it consistently.
Unit test verifies that MikeTerry ‘s individual methods calculate the correct output values given various input values.
Test 6 - Firing: MikeTerry tested that his firing power was consistent. He needed to fire his enemy at the power of 2 or less when the enemy is in the range greater then 200 pixel.
During the testing phase, I discovered that my coding style didn't require alot of changes for testing. Here is MikeTerry tests and results.
Coach's last words: It is easier to code with testing in mind versus coding like a mad programmer and finding bugs everywhere to drive you to be even more mad.
Acceptance tests are to be making sure that MikeTerry can consistently beat one or more of the sample robots that I have been using in previous assignments.
Test 1- MikeTerry VS. Fire: MikeTerry constantly won against this robot.
Test 2 - MikeTerry VS. Crazy: MikeTerry constantly won against this robot.
Behavioral tests make sure that MikeTerry that his movements and strategies are on point.
Test 3 - Clockwise path: As part of MikeTerry’s strategy, he needs to move clockwise; by doing this test I was able to see that MikeTerry always used a clockwise path without making any changes in his coding.
Test 4 - All 4 corners: One of the other strategies is to move to all four corners, which MikeTerry did successfully without any major changes in his coding.
Test 5 - Out of the center: I wanted for MikeTerry to stay within the outter wall radius and he did it consistently.
Unit test verifies that MikeTerry ‘s individual methods calculate the correct output values given various input values.
Test 6 - Firing: MikeTerry tested that his firing power was consistent. He needed to fire his enemy at the power of 2 or less when the enemy is in the range greater then 200 pixel.
During the testing phase, I discovered that my coding style didn't require alot of changes for testing. Here is MikeTerry tests and results.
Coach's last words: It is easier to code with testing in mind versus coding like a mad programmer and finding bugs everywhere to drive you to be even more mad.
Subscribe to:
Posts (Atom)