Timeline for How do you unit-test code using graph structures?
Current License: CC BY-SA 4.0
28 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 29, 2023 at 0:10 | answer | added | Flater | timeline score: 1 | |
| Jun 28, 2023 at 21:21 | answer | added | John Zabroski | timeline score: 0 | |
| Dec 19, 2018 at 22:01 | history | edited | Sled | CC BY-SA 4.0 |
improve title
|
| S Apr 17, 2015 at 15:03 | history | bounty ended | Stas Bichenko | ||
| S Apr 17, 2015 at 15:03 | history | notice removed | Stas Bichenko | ||
| S Apr 16, 2015 at 12:37 | history | suggested | mk7 | CC BY-SA 3.0 |
Add an addition to the problem statement originally posted in a comment.
|
| Apr 16, 2015 at 12:14 | review | Suggested edits | |||
| S Apr 16, 2015 at 12:37 | |||||
| Apr 14, 2015 at 11:45 | answer | added | sdenham | timeline score: 2 | |
| Apr 14, 2015 at 0:58 | answer | added | Low Flying Pelican | timeline score: 2 | |
| Apr 13, 2015 at 23:51 | comment | added | mlvljr | factor the logic either a) changing the state of a graph or b) producing some data given a graph into standalone-ish "methods" -- and test those with properly crafted inputs; this will guard you against the unit tests becoming integrated ones in disguise (where integrated would be multiple invokations of same logic, essentially -- with its correctness obscured by the chain of intermediate states, just like the interaction of multiple components would obscure their individual behaviors with "normal" integration tests) | |
| Apr 13, 2015 at 18:06 | answer | added | Macke | timeline score: 6 | |
| Apr 13, 2015 at 12:02 | comment | added | sdenham | Cycle detection is a well-covered topic (see Knuth, and also some answers below) and the solutions do not involve a large number of special cases, so you should first determine what makes your problem like this. Is it due to the contradictions you mention? If so, we need more information about them. If it is a result of implementation choices, you may have to refactor, perhaps in a big way. Fundamentally, this is a design problem you will have to think your way through, TDD is the wrong approach that can take you deep into the maze before you dead-end. | |
| Apr 13, 2015 at 10:40 | comment | added | SpaceTrucker | What you describe sounds more like integration testing and not like unit testing. Unit tests would make sure that a method is able to find the circles in a graph. Other unit tests would make sure that a specific circle of a specific graph is handled by the class under test. | |
| Apr 12, 2015 at 15:20 | answer | added | Harry Pehkonen | timeline score: 3 | |
| Apr 11, 2015 at 11:13 | answer | added | Ext3h | timeline score: 7 | |
| Apr 10, 2015 at 15:16 | answer | added | Doc Brown | timeline score: 7 | |
| S Apr 10, 2015 at 13:48 | history | bounty started | Stas Bichenko | ||
| S Apr 10, 2015 at 13:48 | history | notice added | Stas Bichenko | Draw attention | |
| Jan 12, 2015 at 7:38 | audit | Close votes | |||
| Jan 12, 2015 at 7:39 | |||||
| Dec 21, 2014 at 9:15 | audit | Reopen votes | |||
| Dec 21, 2014 at 9:16 | |||||
| Dec 15, 2014 at 16:10 | comment | added | Dunk | That is the problem with any form of testing. All you know is that the tests that you thought of work. It doesn't mean your sw is error free just because your tests pass. Every project has that same problem. I'm in the final stages of delivering my current project so we can begin manufacturing. The types of errors we come across now tend to be rather obscure. Such as, where the hardware still works up to spec but just barely and when combined with other hardware simultaneously with the same issue then problems happen; but only sometimes:( The sw is well tested but we didn't think of everything | |
| Dec 12, 2014 at 15:04 | comment | added | Sled | @Dunk We keep thinking that we have all the tricky ones covered and then we realise that a certain structure causes problems we hadn't considered before. Testing every tricky that we can think of is what we are doing, what I'm hoping to find is some guidelines/procedures to generating troublesome examples maybe using reducibility of fundamental forms etc. | |
| Dec 12, 2014 at 9:38 | history | tweeted | twitter.com/#!/StackProgrammer/status/543338989210828800 | ||
| Dec 12, 2014 at 6:02 | answer | added | BobDalgleish | timeline score: 3 | |
| Dec 11, 2014 at 21:49 | comment | added | Dunk | Same way you unit test any other method. You identify all the "interesting" test cases for each method and write unit tests for them. In your case, you'll have to create canned dependency graphs for each of the "interesting" graph structures. | |
| Dec 11, 2014 at 18:45 | history | edited | Sled | CC BY-SA 3.0 |
or -> xor
|
| Dec 11, 2014 at 18:03 | history | edited | Sled | CC BY-SA 3.0 |
added 180 characters in body
|
| Dec 11, 2014 at 17:49 | history | asked | Sled | CC BY-SA 3.0 |