DOC PREVIEW
Penn CIT 597 - Unit Testing in Ruby

This preview shows page 1-2-19-20 out of 20 pages.

Save
View full document
Premium Document
Do you want full access? Go Premium and unlock all 20 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

Unit Testing in Ruby Jan 14 2019 Programming methodologies The grim facts The majority of large programming projects fail Projects that succeed are usually full of bugs Modifying and debugging programs usually introduces yet more bugs Hence it is hazardous to modify a working program The time spent maintaining a program far exceeds 10x the amount of time it took to write the program Programming methodologies are attempts to solve these problems by properly organizing programs and or programmers The current and best methodologies are the agile methodologies Agile means writing software that is easily changed XP Exteme Programming is the best known agile methodology XP tends to work best for small groups of programmers Some ideas from agile programming There is no silver bullet but agile methodologies are the best we have at present Most large programming projects fail so Write the simplest thing that can possibly work Always have a working version no matter how little it does Never add a feature until all known bugs have been fixed Any code that hasn t been tested is assumed to be wrong Have tests for all code and keep it up to date Run tests frequently very frequently Tests must be trivially easy to run or you won t bother running them Test suites Obviously you have to test your code to get it working in the first place You can do ad hoc testing running whatever tests occur to you at the moment or You can build a test suite a thorough set of tests that can be run at any time Disadvantages of a test suite It s a lot of extra programming You don t have time to do all that extra work This is true but use of a good test framework can help quite a bit False Experiments repeatedly show that test suites reduce debugging time more than the amount spent building the test suite Advantages of a test suite Reduces total number of bugs in delivered code Makes code much more maintainable and refactorable This is a huge win for programs that get actual use XP approach to testing In the Extreme Programming approach Tests are written before the code itself If code has no automated test case it is assumed not to work A test framework is used so that automated testing can be done after every small change to the code This may be as often as every 5 or 10 minutes If a bug is found after development a test is created to keep the bug from coming back Consequences Fewer bugs More maintainable code Continuous integration During development the program always works it may not do everything required but what it does it does right Terminology A test fixture sets up the data both objects and primitives that are needed to run tests Example If you are testing code that updates an employee record you need an employee record to test it on A unit test is a test of a single class A test case tests the response of a single method to a particular set of inputs A test suite is a collection of test cases A test runner is software that runs tests and reports results An integration test is a test of how well classes work together JUnit provides some limited support for integration tests Once more in pictures test suite test runner another unit test test case for one method another test case another unit test another test case another test case another test case unit test for one class test case for one method another test case test fixture A unit test tests the methods in a single class A test case tests insofar as possible a single method You can have multiple test cases for a single method A test suite combines unit tests The test fixture provides software support for all this The test runner runs unit tests or an entire test suite Integration testing testing that it all works together is not well supported by JUnit The test runner The test runner runs all your tests If they all succeed you get a green bar If any fail you get a red bar and links to the tests that failed How not to write a unit test Unit tests must be fast and easy to run or you won t run them The only output you should need to look at in order to see that all tests passed at is the green bar Of course if you get a red bar you need to explore further Don t do any output from your unit tests Ideally the methods you are testing should not do any output In most well written programs there is a separation of concerns methods either compute or do output but not both It is possible to write unit tests for methods that do output but that is a slightly advanced topic I won t cover here How to write a unit test class A unit test class is a class you write that extends Test Unit TestCase You will need the line require test unit Your test class will inherit the following methods def setup def teardown This a method that will be called before each of your test methods Typically you will override this method and use it to assign values to some instance variables you need in testing This a method that will be called after each of your test methods Typically you will just ignore this method unless you need to close files You will also write any number of test methods all of which have the form def test Something Something is usually but not necessarily the name of the method you want to test Inside each test method you will do some computations and call one or more assert methods to test the results Available assertion methods assert boolean assert equal expected actual assert same expected actual Uses Uses equal assert not equal expected actual assert not same expected actual assert nil object assert not nil object assert block block All these methods can take an additional message argument This is not a complete listing of the assert methods The first two methods are by far the most commonly used Structure of a unit test require test unit require file to be tested class CountTest Test Unit TestCase def setup Perform initializations here end def test some method Tests go here end def teardown Release any resources usually not needed end end Testing for exceptions Methods should throw exceptions if they are called incorrectly You can test whether a method throws an exception when it ought to def test exceptions begin Call the method that should throw an exception rescue Exception or you can test for specific exceptions return The exception happened so the test passes end flunk end Ruby also has assert raise and assert throws methods but I haven t been able to make them work A complete example class Counter attr reader value def initialize value 0 end def increment


View Full Document

Penn CIT 597 - Unit Testing in Ruby

Documents in this Course
DOM

DOM

21 pages

More DOM

More DOM

11 pages

Rails

Rails

33 pages

DOM

DOM

21 pages

RELAX NG

RELAX NG

31 pages

RELAX NG

RELAX NG

31 pages

RELAX NG

RELAX NG

31 pages

RELAX NG

RELAX NG

31 pages

Rake

Rake

12 pages

Ruby

Ruby

58 pages

DOM

DOM

21 pages

Tomcat

Tomcat

16 pages

DOM

DOM

21 pages

Servlets

Servlets

29 pages

Logging

Logging

17 pages

Html

Html

27 pages

DOM

DOM

22 pages

RELAX NG

RELAX NG

30 pages

Servlets

Servlets

28 pages

XHTML

XHTML

13 pages

DOM

DOM

21 pages

DOM

DOM

21 pages

Servlets

Servlets

26 pages

More CSS

More CSS

18 pages

Servlets

Servlets

29 pages

Logging

Logging

17 pages

Load more
Download Unit Testing in Ruby
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Unit Testing in Ruby and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Unit Testing in Ruby and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?