Skip to main content
24 events
when toggle format what by license comment
Jun 19, 2019 at 11:12 answer added Laurent LA RIZZA timeline score: 1
Jun 19, 2019 at 7:52 answer added candied_orange timeline score: 3
Jun 19, 2019 at 7:32 comment added Luaan @franiis TDD is built around iteration. Write failing test. Write code that makes the test green. Refactor. Write a failing test. Write code that makes the test green. Refactor. It seems that you're missing the part "repeat until you have tests that cover all of your requirements". But the biggest problem you seem to have is that "tests" are seen as something you must have because somebody said so, rather than tests being a useful tool for the developers. If you can't get people to care about the quality (and correctness) of their code, that's your problem, and that's where you should start.
Jun 18, 2019 at 13:39 answer added Borjab timeline score: 4
Jun 18, 2019 at 8:27 comment added fdomn-m Biggest issue with 2 people writing features and then swapping to write tests: how often do you have two features that take exactly the same amount of development time? Never.
Jun 18, 2019 at 8:08 answer added l0b0 timeline score: 1
Jun 18, 2019 at 5:33 vote accept franiis
S Jun 18, 2019 at 5:28 history suggested Peter Mortensen CC BY-SA 4.0
Copy edited (e.g. ref. <http://www.wikihow.com/Use-Than-and-Then> and <https://en.wiktionary.org/wiki/doesnt#Verb>).
Jun 18, 2019 at 3:00 history tweeted twitter.com/StackSoftEng/status/1140816487588007936
Jun 18, 2019 at 1:24 comment added Eric Duminil @franiis I've seen colleagues write assert true as tests and call it a day because every test was passing. One important step was missing : the tests should fail first, and should be made to pass by changing the code, not the tests.
Jun 18, 2019 at 0:21 review Suggested edits
S Jun 18, 2019 at 5:28
Jun 17, 2019 at 18:48 history became hot network question
Jun 17, 2019 at 13:24 answer added Robbie Dee timeline score: 7
Jun 17, 2019 at 13:24 answer added Doc Brown timeline score: 16
Jun 17, 2019 at 13:00 answer added Thomas Owens timeline score: 30
Jun 17, 2019 at 12:16 comment added franiis Yes, that great idea. One developer would be "lead" for one feature and another would lead second feature (as pair of developers get two features at the same time).
Jun 17, 2019 at 12:16 comment added jonrsharpe That criticism makes no sense, and your suggestion doesn't solve that problem.
Jun 17, 2019 at 12:03 history edited Robbie Dee CC BY-SA 4.0
deleted 1 character in body
Jun 17, 2019 at 12:00 comment added Martin Maat This would work better if the test writer would do the tests first (write skeleton code) and the other one implemented the functionality. The first one would be in control of the design and the other one would do the heavy lifting. That could work well if the first one knows what he is doing and the second one does not mind following his lead all the time. I do not know about a name for this way of co-operation. I would say.. claim it! Start calling this Franiis development.
Jun 17, 2019 at 11:44 comment added franiis @jonrsharpe Thanks for pointing this out. As I responded to answer - TDD faces critique as developers could write code that are passing test, not correct. My idea should mobilize to writing code, that second developer won't be ablo to break so easily.
Jun 17, 2019 at 11:13 answer added Ewan timeline score: 37
Jun 17, 2019 at 11:07 comment added jonrsharpe You're just describing downstream QA at the unit level. If you have pairs of people working on something, have you tried actual pair programming with TDD?
Jun 17, 2019 at 10:35 review First posts
Jun 17, 2019 at 14:21
Jun 17, 2019 at 10:34 history asked franiis CC BY-SA 4.0