Title: EEEGEF 492'lab2intro TDD: Symbol Table using Junit
1EEE/GEF 492.lab2intro TDD Symbol Table using
Junit Java
Royal Military College of Canada Electrical and
Computer Engineering
Dr. Terry Shepard shepard_at_rmc.ca 613-541-6000
ext. 6031
2Outline
- Purpose of Lab 2
- TDD Test Driven Development
- an explicit and important part of XP
- Unit Testing Frameworks
- JUnit
- Getting started with Junit
3Purpose of Lab 2
- Explore the use of TDD, Junit and Java for the
eventual development of a symbol table component
for use in a Java debugger - Use the symtbl work products from Lab 1 as the
starting point - Add a type for each symbol
- Add a memory model, contents of memory
- Add ability to print symbol values formatted
according to their types
4TDD Test Driven Development
- One of the key practices of eXtreme Programming
(XP) - Other key practices include pair programming and
refactoring - There is ongoing debate about whether it is
necessary to use all the practices at once
5TDD is a Hot Topiceg. article in Sept. 2005
issue of Computer magazine from the IEEE
- Test-Driven Development Concepts, Taxonomy, and
Future Direction, by David Janzen, Simex LLC and
Hossein Saiedian, University of Kansas
6from JUnit in Action
Manning Publications, 2003, by Vincent Massol
and Ted Husted
- Test-driven development (TDD) is a programming
practice that instructs developers to write new
code only if an automated test has failed, and to
eliminate duplication. The goal of TDD is clean
code that works.
7From the Agile Alliance
- Test-driven development (TDD) is the craft of
producing automated tests for production code,
and using that process to drive design and
programming. For every tiny bit of functionality
in the production code, you first develop a test
that specifies and validates what the code will
do. You then produce exactly as much code as will
enable that test to pass. Then you refactor
(simplify and clarify) both the production code
and the test code.
8from Janzen and Saiedian
- As Beck states, XP takes the known best
practices and turns the knobs all the way up to
ten. Many developers might have been thinking
and coding in a test-first manner, but TDD does
this in an extreme way always writing tests
before code, making tests as small as possible,
and never letting code degrade. TDD fits within a
process model, and the development of
incremental, iterative, and evolutionary process
models has been vital to its emergence.
Kent Beck, Aim, Fire, IEEE Software,
Sept./Oct. 2001, pp. 87-89.
9from Janzen and Saiedian
- Tools have played an important role in the
emergence of TDD, which assumes the existence of
an automated unit testing framework. Such a
framework simplifies both the creation and
execution of software unit tests. Test harnesses,
basically automated testing frameworks, provide a
combination of test drivers, stubs, and
interfaces to other subsystems. Often such
harnesses are custom-built, although commercial
tools do exist to assist with test harness
preparation.
10from Janzen and Saiedian
- The proliferation of software tools that support
TDD shows that it has widespread support and will
likely become an established approach. JUnits
simplicity and elegance have been a significant
factor in TDDs use, particularly in the Java
community. Programmers can develop unit tests
easily and execute large test suites with a
single button click, yielding quick results about
the systems state.
11from Janzen and Saiedian
- TDD has yet to achieve widespread acceptance in
academia, at least partly because faculty who do
not specialize in software engineering are not
likely to be familiar with it. TDD instructional
materials that target undergraduate courses
remain basically nonexistent.
12from Janzen and Saiedian
13from Janzen and Saiedian
The Edwards study used novice programmers
14from Janzen and Saiedian
- Both industry and academic settings can benefit
from more research. In particular, academic
studies need to examine whether TDD improves or
at least does not hinder learning. Can TDD be
incorporated into the undergraduate curriculum in
a way that improves students ability to design
and test? If so, then TDD must be written into
appropriate student texts and lab materials.
15Unit Testing in TDD
- Motto Clean code that works. (Ron Jeffries)
- Unit testing has broader goals that just
insuring quality - Improve developers lives (coping, confidence)
- Support design flexibility and change
- Allow iterative development with working code
early
based on slides from CS494, University of Virginia
16Unit Testing Benefits
- Developers can work in a predictable way of
developing code - Programmers write their own unit tests
- Get rapid response for testing small changes
- Build many highly-cohesive loosely-coupled
modules to make unit testing easier
based on slides from CS494, University of Virginia
17Red/Green/Refactor
- The TDD mantra of how to code
- Red write a little test that doesnt work,
perhaps even doesnt compile - Green Write code to make the test work quickly
(perhaps not the best code) - Refactor Eliminate duplication and other
problems that you did to just make the test work
based on slides from CS494, University of Virginia
18What is a framework?
- In software development, a framework is a defined
support structure in which another software
project can be organized and developed. A
framework may include support programs, code
libraries, a scripting language, or other
software to help develop and glue together the
different components of a software project. The
word "framework" has become a buzzword due to
recent continuous and unfettered use of the term
for any generic type of libraries. Sometimes, the
word framework is used in place of the synonomous
term, library, for the purpose of impressing
venture capitalists.
definition from http//en.wikipedia.org/wiki/Frame
work -- note that the examples given do not
include unit testing frameworks
19Do we call it unit testing?
- many in the Extreme Programming community favor
the terms "developer testing" or "programmer
testing" over the term "unit testing," since many
other test activities (like function or
acceptance test) can now be done at
"developer-time." - from http//en.wikipedia.org/wiki/Unit_test
20Unit Testing Frameworks (UTFs)
- http//en.wikipedia.org/wiki/List_of_unit_testing_
frameworks - http//en.wikipedia.org/wiki/XUnit
- http//opensourcetesting.org/
- Junit http//www.junit.org/index.htm
21Junit Architecture
voir http//www.progx.org/index.php?sectionarticl
esarticleJava/article14 -- en français for
more details, see http//junit.sourceforge.net/doc
/cookstour/cookstour.htm
22Getting started in Junit
- Junit.org
- cook book, FAQ, cooks tour
- Lab 3 from eee/gef 321B last winter
- Tutorial www.cs.umanitoba.ca/eclipse/10-JUnit.pd
f
23writing Junit tests
- How do I write a simple test?
- Create a subclass of TestCase
- Write a test method
- Write a suite() method
- Write a main() method
based on http//junit.sourceforge.net/doc/faq/faq.
htm
241. Create a subclass of TestCase
- package junitfaq
-
- import java.util.
- import junit.framework.
-
- public class SimpleTest extends TestCase
//paren closed on a future slide
based on http//junit.sourceforge.net/doc/faq/faq.
htm
252. Write a test method
- Write a test method to assert expected results on
the object under test - public void testEmptyCollection()
- Collection collection new ArrayList()
- assertTrue(collection.isEmpty())
-
-
based on http//junit.sourceforge.net/doc/faq/faq.
htm
263. Write a suite() method
- Write a suite() method that uses reflection to
dynamically create a test suite containing all
the testXXX() methods - public static Test suite()
- return new TestSuite(SimpleTest.class)
-
-
based on http//junit.sourceforge.net/doc/faq/faq.
htm
274. Write a main() method
- Write a main() method to conveniently run the
test with the textual test runner - public static void main(String args)
- junit.textui.TestRunner.run(suite())
-
- //closing paren from item 1. above
-
based on http//junit.sourceforge.net/doc/faq/faq.
htm
28Lab 3 from eee/gef 321B
- http//phillips.rmc.ca/courses/321-2005/labos/lab
3.html - http//tarpit.rmc.ca/paul/EEE321B/Lab3/EEE321B_La
b03.html - repeat the steps from 321 to make sure you have
Junit up and working properly - use the test cases there as a model for getting
started constructing your test cases for symtbl
29Today in Lab 2
- Follow one or more of the three Getting Started
in Junit steps proposed above. - Create at least one junit test for a java version
of symtbl, and write enough code to get a green
bar.