- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
The frist goal of unit testing is to get the code coverage percentage as high as possible, right?
Admin
On the plus side, they used declarative code in their unit test and didn't use a prohibited loop to create all unit test cases.
Admin
yepp, code coverage is the goal, if it tests sensible situations is not required
Admin
That doesn't look like xUnit to me, I guess good old nUnit. And no Dragnslcr, code coverage is about covered execution branches, that method doesn't have one. It's just wasting CPU circles cause nUnit is also known for not being very efficient.
Addendum 2024-06-18 06:56: Nvm, the article talks about SQL-construction, so I guess you have a ton of actual execution branches there.
Admin
This test ensures that connection to the database is successful, there is enough disk space on the database server, and that INSERT statement is generated correctly. Very beneficial!!
Admin
Exactly! Plus we're ensuring that the database fields still accept Boolean values! Who knows what those sneaky DBAs might try to pull?
Admin
Pre-Setting for as the method is developed to make sure that none of the combinations throw an exception.
Admin
I'm glad they didn't add FileNotFound as a third boolean value in that codebase. Imagine the number of test cases there would be!
Admin
In Javaland, we'd write a method that generates the permutations, then put
@MethodSource("theNameOfThatMethod")on the test case. It still keeps the looping separate from the testing, and the test report will consider them separate cases (so iftrue, false, truefails, that one in particular will be highlighted), just like any argument source. I don't see any reason to prefer manually enumerating the cases.If the above comment was ironic, ignore this, I suppose.
Admin
Coverage can't be that good without testing for combinations with the boolean value FILE_NOT_FOUND
Admin
is it just me or the test method is actually empty?
Admin
looks empty for me, too
Admin
For a job that lives and dies on understanding what you are doing and why, there sure are a lot of people who simply don't. Not even a little bit.
Admin
If only we could generate random combinations using a function. Oh, wait...
Admin
This does bring up a point though. In a lot of cases, your app doesn't have individual functionality to test, it's based off of sending/reading some data and doing something with that. For example, at work we have an app which wraps a 3rd party DLL, and is entirely run off of JSON sent by the consuming application. So we have no good way to test this because it's all based around feeding it a json document, parsing that and passing it to the 3rd party DLL, and spitting out the results.
We could mock json files for things, but that's a bit ridiculous IMHO.
Admin
Hey, I'm late to the party; but I don't have a problem with passing every possible combination of values to the test method. I WOULD expect there to be an assertion, so one of the values (the last one in each row) should be the expected result.
By passing every possible combination of values, you absolutely ensure that the method being tested behaves as expected.
Admin
That by itself doesn't have to be bad. From the callers point of view, this may indeed update records, even if, behind the scenes, you're doing inserts.
Admin
There's nothing ridiculous about having internal unit tests for your json wrangling, though I would expect that most of the testing would end up being integration tests (as much as it can be tested through the third-party components).