IS211 CUNY Week 6 Testing and Refactoring Python Programming The PDF file contains the instructions and also there is some helpful info below: This week,

IS211 CUNY Week 6 Testing and Refactoring Python Programming The PDF file contains the instructions and also there is some helpful info below:

This week, we focused on how to build tests for our software and how to refactor our code to be simpler or more efficient. For this week’s assignment, we are going to build some functions that will help us do some temperature unit conversions. We will start by writing out tests that fail, and then building some code to make that test pass, until we have a working version of the application. After that, we will see how we can potentially refactor this implementation into something simpler.

Here are some useful chapters that may help you connor:

Chapters 13, 14 and 15 in “Dive Into Python”, which covers testing and refactoring

Dive Into Python – http://diveintopython3.problemsolving.io/ Week 6 Assignment ­ Testing and Refactoring
Overview
This week, we focused on how to build tests for our software and how to refactor our code to be simpler or
more efficient. For this week’s assignment, we are going to build some functions that will help us do some
temperature unit conversions. We will start by writing out tests that fail, and then building some code to
make that test pass, until we have a working version of the application. After that, we will see how we can
potentially refactor this implementation into something simpler.
Our code will be organized into two files:
1.
2.
conversions.py, which holds functions that will do these temperature unit conversions? and
tests.py, which will hold all of our tests
Make sure to create a github repository for this assignment named IS211_Assignment6. All development
should be done in this repository.
Useful Reminders
1.
2.
Read the assignment over a few times. At least twice. It always helps to have a clear picture of the
overall assignment when understanding how to build a solution.
Think about the problem for a while, and even try writing or drawing a solution using pencil and
paper or a whiteboard.
Part I ­ Create Tests for Celsius Conversion
Following the test­driven development methodology, we are going to start by first creating some tests for our
implementation. Let us start with testing two functions that we will eventually need to write and put inside
conversions.py:
1.
2.
convertCelsiusToKelvin­ Takes in a float representing a Celsius measurement, and returns that
temperature converted into Kelvins
convertCelsiusToFahrenheit­ Takes in a float representing a Celsius measurement, and returns
that temperature converted into Fahrenheit
For now, create these functions in the correct file but have them return 0.0.
The tests should make multiple calls to each function, checking if the conversion is correct. For example,
300.00 °C is 572.00 °F and 573.15 K. For more information on how to do these conversions, please refer to
Conversion of Units of Temperature webpage, which has a reference table of known conversions that you
can use for your testing. Make sure this test is thorough by including 5 test cases per test. Also make sure to
be verbose in your testing (i.e. print a message for every test case you are checking).
At this point, since those functions have not been written properly, the tests will fail. Let us correct this in the
next section.
Part II ­ Implement the Celsius Conversion Functions
Now we need to make the tests work. Do this by correctly implementing the conversion functions listed
above. Make sure all your tests at this point run without any errors.
Part III ­ Repeat
Repeat Part I and II for converting from Fahrenheit to Celsius and Kelvin, as well as converting from Kelvin
to Fahrenheit and Celsius. There should now be a total of 6 functions, each one having a test case which
confirms it is properly converting. Make sure all your tests can run successfully.
Part IV ­ Refactor
In many real world situations, the requirements for your code may change. It behooves you as a
programmer to think in general terms, such that if requirements do change, you can minimize the impact of
how your code needs to change. Lets mimic this by changing the requirements of the application to support
not only temperature, but to support converting between Miles, Yards and Meters.
Now, to support this, we can do like we did above: keep creating functions to convert one unit to another,
and writing a test for that function to confirm its functionality. However, is there a more general way to solve
these conversion problems? Do they have a similar pattern? If they do, is there a way for you to refactor
your code such that you only need one functions to convert any unit into another (of course, we can’t convert
Celsius to Meters, and we should account for that by throwing an exception).
Lets create a new method inside of a new file (called conversions_refactored.py) named convertthat takes
in 3 values:
1.
2.
3.
fromUnit ­ the unit we are converting from, as a string
toUnit ­ the unit we are converting to, as a string
value ­ the value of fromUnit we are converting from
The function should return the converted value as a float. This method should not rely on the methods we
wrote above. This about the problem and see if a pattern emerges that lets you implement it in a simpler
way. The test for this function should:
1.
2.
3.
4.
Check that all temperature conversions are working
Check that all distance conversions are working
Check that converting from one unit to itself returns the same value for all units
Check that converting from incompatible units will raise a ConversionNotPossibleexception
(which should be defined in the conversions_refactored.py file)
Week 6 ­ Lecture Notes
Welcome to Week 6!
This week we will go over an important concept that transcends specific programming
languages, and that is unit testing. You should be familiar with testing from the previous IS210
class, where tests were being run against your code every time you made a commit to your git
repository for an assignment.
First off, lets define what we mean by unit testing. A unit refers to the small testable parts of
an application. Unit testing is simply the process by which we individually and independently
verify the unit for proper operation. How you define the exact boundaries of what a ‘unit’
entails depends on many factors, like how your application is structured and what the purpose
of the application is. A unit could be an entire module, but it is more commonly an individual
function or procedure. When dealing with OOP, a unit can be an entire class or the class’
individual methods. However, at the end of the day, a unit is however you define it.
Writing good tests for your units of code, however defined, is a bit of an inexact science. Good
unit tests at the end of the day are verifying that your code does what it should be doing?
obviously, this insinuates that you have a deep understanding of the requirements of your
code to begin with. If you do not have a clear grasp of what your code should be doing, you
should not be writing tests yet, and focus on defining the purpose of the unit in question.
There is a lot of information on how to develop good, informative software requirements,
which this course will not cover. If you are interested in this, however, you can check out
these resources:
? Software Requirements, 3rd Edition
? Code Complete, 2nd Edition
There are other kinds of testing as well, besides unit testing, including:
? Regression testing ­ tests that ensure that bugs that have been found and fixed do
not come back in future releases of the code
? Software performance testing ­ tests that are used to determine how some code
performs in terms of speed, responsiveness or usage of resources.
? Security testing ­ tests that help determine whether or not the code under review is
vulnerable to security issues, like critical data being exposed. What is interesting about
security testing is that passing a security test does not mean that there are no security
flaws at all. It only means that the code is not vulnerable to the flaws you are testing.
This week we will focus on how we can write theses tests ourselves by reviewing a practical
application from “Dive In Python”. The reading will cover code that deals with handling Roman
Numerals and how to approach testing and verifying that this code does what we need it to.
The reading will also cover an idea called refactoring, which is the process by which you take
already working code and make it better in some form. Of course, its tough to refactor code
and ensure that you have not introduced bugs without testing, which is one of the main
benefits of testing your code to begin with.

Purchase answer to see full
attachment