StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>It doesn't really matter what tested method calls under the hood - this is implementation detail and your unit tests shouldn't be <em>much</em> aware of that. Usually (well, most of the time with unit testing) you want to test <em>single unit</em> and focus on that.</p> <p>You could either write separate, isolated tests for each public method in your class or refactor part of functionality of your tested class outside. Both approaches focus on same thing though - having isolated tests for each <em>unit</em>.</p> <p>Now, to give you few hints: </p> <ul> <li>what is the name of your tested class? Basing on methods it exposes, something along the lines of <code>ExcelExporterAndToDataSetConverter</code> ... or <code>ExcelManager</code>? It seems as this class might be doing <a href="http://en.wikipedia.org/wiki/Single_responsibility_principle" rel="nofollow">too many things at once</a>; this asks for bit of refactoring. Exporting data to DataSet can be easily separated from converting excel data to DataSets/DataRows.</li> <li>what happens when <code>GetDataTableFromExcelSheet</code> method changes? Gets moved to other class or is replaced by 3rd party code? Should it break your export tests? It shouldn't - this is one of the reasons your export tests shouldn't verify whether it was called or not.</li> </ul> <p>I suggest moving to DataSet/DataRow conversion methods to separate class - it will ease writing of the unit tests and your export tests won't be as fragile.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload