Timeline for How to test when arranging the data is too cumbersome?
Current License: CC BY-SA 3.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 23, 2017 at 12:40 | history | edited | CommunityBot | replaced http://stackoverflow.com/ with https://stackoverflow.com/ | |
| Aug 4, 2016 at 10:46 | history | edited | svick | CC BY-SA 3.0 | syntax highligting |
| Aug 4, 2016 at 10:45 | vote | accept | svick | ||
| Dec 8, 2014 at 7:37 | audit | First posts | |||
| Dec 8, 2014 at 7:38 | |||||
| Dec 5, 2014 at 3:10 | comment | added | Chris Hayes | +1 for @DanNeely's approach. We use something similar to store several serialized versions of our data model as test data, so that we can be sure new code can still work with older data. | |
| Dec 4, 2014 at 22:18 | comment | added | Dan Is Fiddling By Firelight | Something I've done in cases where the parser itself is an expensive operation (eg reading data out of Excel files via com interop) is to write test generation methods that run the parser and output code to the console recreate the data structure the parser return. I then copy the output from the generator into more conventional unit tests. This allows reducing the cross dependency in that the parser only needs to be working correctly when the tests were created not every time they're run. (Not wasting a few seconds/test to create/destroy Excel processes was a nice bonus.) | |
| Dec 4, 2014 at 18:33 | comment | added | Jonathan Eunice | @SteveJessop Good point. It's important to use independent components. | |
| Dec 4, 2014 at 18:15 | comment | added | Steve Jessop | The main purity concern (I think) is to avoid writing circular dependencies in your unit tests. If either the parser or the parser tests use the expander, and this expander test relies on the parser working, then you have a difficult-to-manage risk that all you're testing is that the parser and the expander are consistent, whereas what you wanted to do was test that the expander actually does what it's supposed to. But as long as there's no dependency back the other way, using parser in this unit test isn't really any different from using a standard library in a unit test. | |
| Dec 4, 2014 at 16:25 | comment | added | Jon Story | This is sensible - especially regarding the fact that everything depends on many others. A good unit test should test the minimum possible. Anything that is within that minimum possible amount should be tested by a preceeding unit test. If you've completely tested Parser, you can assume that you can safely use Parser to test ParseStatement | |
| Dec 4, 2014 at 15:21 | history | answered | Jonathan Eunice | CC BY-SA 3.0 |