Selaa lähdekoodia

Added more beef to the testing chapter

Peter J. Jones 10 vuotta sitten
3 muutettua tiedostoa jossa 109 lisäystä ja 15 poistoa
  1. +6
  2. +11
  3. +92

+ 6
- 3
README Näytä tiedosto

@@ -15,18 +15,21 @@
- Testing Techniques
- Black-box testing
- White box testing
- Testing Scopes
- Unit Testing
- Integration Testing
*** Ruby Testing Facilities
- Test::Unit library
- Brief mention of RSpec and Cucumber
- List of test unit assertions
- Mocking
- Fuzzing
*** Levels of Testing
- Unit Testing
- Integration testing
*** Writing Effective Tests
- Write them before you write the code
- Get them to fail
*** Chapter Recipes
- Replacing a method without mocking because of side effects
(setting a variable)
** Content Ideas
*** Blocks
**** Knowing if a block takes arguments

+ 11
- 0
adv-ruby.tex Näytä tiedosto

@@ -18,6 +18,14 @@

% ============================================================================

% ============================================================================

% ============================================================================
@@ -37,6 +45,7 @@


% ============================================================================
@@ -63,5 +72,7 @@



% ============================================================================

+ 92
- 12
chapters/testing.tex Näytä tiedosto

@@ -24,33 +24,113 @@ This chapter quickly moves through the basics of testing and then
slows down for a full treatment of advanced testing.

% ============================================================================
\section{What Testing Is and Isn't}
\section{What Automated Testing Is and Isn't}

\todo{Upfront cost that pays dividends.}
If you stop to think about it, you're going to test your software no
matter what. Nobody who can rightfully call themselves a developer
writes code and then pushes it directly to production without at least
running the software.

\todo{100\% code coverage doesn't make sense.}
Nearly everyone can therefore claim they test their software. Can you
claim to run the same exactly tests exactly the same way each time?
If it isn't captured into a script and automated you should definitely
answer ``No''.

\subsection{Approaches to Testing}
It takes time to start your software and run through the most
important features to make sure it works. Each time you do that
you're just wasting your time. Wouldn't it be easier to write that
process into a script that you could then run over and over again?

\todo{TDD, BDD, Black-box, white-box, etc.}
Even a single, simple automated test is a huge improvement over manual
testing. When it comes to a dynamic language like Ruby, automated
testing is a must.

\subsection{Testing Doesn't Prove Correctness}

Even if you have a fairly robust and comprehensive test suite your
software might still have bugs. Testing can dramatically increase the
confidence in your software, but it can't ensure that it will always
work correctly.


While there has been work to mathematically prove the correctness of
software, outside of academia we're still stuck with implementation

\subsection{Coverage Metrics}

\index{testing!code coverage|(}

Tools like \Link{}{rcov} tell you
how much of your code your tests actually execute. Ruby being as
beautifully dynamic as it is you can even find out if that one buggy
line deep inside several branches is ever reached by your test

Coverage metrics can be useful for understanding a complex Ruby
program or in assisting you with writing tests that actually execute
the line of code you're concerned about. When you see metrics such as
``85\% test coverage'' it can be a little unsettling and push you
towards 100\%.

Before you spend too much time trying to achieve complete coverage,
however, keep in mind that it doesn't guarantee bug-free software. It
doesn't guarantee much actually. The only thing it really tells you
is that your test suite invokes every line of your software.

It certainly doesn't tell you what will happen when one of your
methods is passed an array instead of a hash, or when one expects a
well-formed string but receives garbage instead.

On the other hand, it does help you catch some of the downsides of
dynamic languages, such as calling nonexistent methods or calling
methods on \texttt{nil} when you expected a variable to point to a
valid object.

Either way, you should consider the time investment necessary to
increase your code coverage and whether the return on that investment
can justify the financial expenditure.

\index{testing!code coverage|)}

% ============================================================================
\section{Basic Unit Testing and Assertions}
\section{Approaches to Testing}


\todo{TDD, BDD}


\todo{Black-box, white-box, happy path, etc.}


\todo{Unit vs. Integration, Contracts}

% ============================================================================
\section{Ruby Testing Facilities}

\subsection{The Test::Unit Library}

\caption{Example Unit Test}

% ============================================================================
\section{Regression Testing and Mocking}
\subsection{Other Testing Frameworks}



% ============================================================================
\section{Fuzz Testing}
\section{Writing Effective Tests}


% ============================================================================
\section{Integration Testing}
\section{Chapter Recipes}