tag:blogger.com,1999:blog-7451086006168569993.post1033437759688990870..comments2023-02-28T05:48:54.955-05:00Comments on Arbitrary Thoughts: Complex Logic in Unit TestsAndrewhttp://www.blogger.com/profile/17391659235860245424noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-7451086006168569993.post-23425129564363330752014-10-02T15:45:35.694-04:002014-10-02T15:45:35.694-04:00In order to avoid loops, flow control or functions...In order to avoid loops, flow control or functions I have seen programmers do monstrous code duplication and various other atrocities.<br /><br />If the advice is to not put flow control, functions or loops - then I am against it. To me this advice is basically "write unmaintainable unit tests". If the advice is to make unit tests read more like a specification then I am for it. <br /><br />The key difference is that it's possible to write any unit test in such a way that avoids both code duplication and fancy things like loops, flow control, functions; so the unit test reads more like a spec. However, if you can't figure out how to do that then write the loop or whatever because the reasons behind these coding best practices still apply in unit tests.<br /><br />To put it another way, I would rather see a loop where a loop makes sense than an unrolled loop with the loops contents duplicated ten times or so.<br /><br />For example, you see a loop in a unit test. If the advice is there should be no loops in a unit test, the easiest way to fix this is to unroll the loop. This solves nothing, because the unit test still has whatever problem it had originally with the addition of redundant code coming from unrolling the loop. This is the sort of thing I have seen in actual code reviews. This is the sort of thing I've had the unpleasant task of arguing about. This is where I'm coming from.<br /><br />Better solutions to the loop question depend on why the loop exists.....<br /><br />If the loop exists because it's really testing multiple things then those things should be in separate unit tests (with no copy and pasted code setup code). If the loop exists because it's building some test data then that's perfectly fine too - put it in a function. Stick the function somewhere that makes sense and make sure there's some basic test to make sure you're getting what you think you are. If the loop exists to compare the contents of two arrays then you can delete it because there's already a library for that.. etc..<br /><br />So yes, it should read like a spec. But no, you don't get a free pass from coding best practices to accomplish that.Andrewhttps://www.blogger.com/profile/17391659235860245424noreply@blogger.comtag:blogger.com,1999:blog-7451086006168569993.post-89539110106732718312014-10-01T16:48:09.637-04:002014-10-01T16:48:09.637-04:00Maybe a string concatenation isn't a convincin...Maybe a string concatenation isn't a convincing example, but can you really tolerate ifs and loops in your tests?<br />The worst cases I've seen are when the test duplicates the implementation logic of the SUT - rather than giving concrete examples of how it should behave.Anonymoushttps://www.blogger.com/profile/04765456269439067183noreply@blogger.com