Skip to main content
11 events
when toggle format what by license comment
Aug 21, 2024 at 15:08 comment added gnasher729 The reason you don’t want
Jun 21, 2017 at 0:09 comment added user275704 The rule about opinions sounds strange to me since no one is providing citations resulting in "answers" that appear to be opinion; the "like" and "dislike" mechanism appears to be a popularity contest. This leads me to wonder why our field doesn't attempt to quantify methodology. Why not verify the total defect count is reduced by N% when using methodology A vs B? This very much seems like a question directed at the core of software engineering because without quantifying then everything appears to be opinion. I'll keep the rules in mind if I ask this question. Thanks again.
Jun 20, 2017 at 21:56 comment added Doc Brown Beware, asking "how engineers view software" sounds to me like a philosophical question which makes it a candidate for being quickly closed either as "too opinionated" or "too broad". Asking for "trials and studies" will closed by the community, too, since asking for third party resources is explicitly off-topic for this site. Better stick to a narrower focus.
Jun 20, 2017 at 19:18 comment added user275704 @DocBrown A separate question I'm planning on asking is with regards to what kind of trials and studies have been done in the field of software engineering to objectively compare test strategies. I've been searching this site trying to find answers to test questions that reference studies or hard data, but most everything seems to be opinion driven.
Jun 20, 2017 at 19:12 comment added user275704 @DocBrown The point I was making is that how engineers view software has a ripple effect on how they design, test, and recommend test strategies. I suspect the emphasis on behavioral testing is driven by business needs, cost, engineering time, and quality assurance. To businesses, behavioral testing may be "good enough", but different industries and applications may need different levels of validation and correctness.
Jun 20, 2017 at 18:44 comment added Doc Brown Don't get me wrong, but as long as your examples seem to proof the opposite of what you are describing else, as long as your usage of terms like "whitebox testing" looks to be based on a misunderstanding or misconception, it is hard for me to understand what your core question is about. Surely software is about "data and data transformation" from some point of view, on the right level of abstraction, and I have only a vague idea what you mean by "life cycle pattern". But it seems you are drifting away from the original question, and this is a Q&A site, not a discussion forum.
Jun 20, 2017 at 16:18 comment added user275704 I appreciate your feedback @DocBrown but your getting hung up on semantics and examples and your not addressing the core ideas: Do you believe software is about data and data transformation? Do you believe classes are an implementation of the "life cycle" pattern?
Jun 20, 2017 at 12:09 comment added Doc Brown ... and you will also need to use multiple of these methods in a test. If you want to test fread, you need to utilize fopen. For a meaningful test of fseek, you will probably utilize fread to verify you reached the intended file position.
Jun 20, 2017 at 12:01 comment added Doc Brown fopen, fread etc. are operations on a file, using an opaque FILE pointer. You surely do not want to write any tests utilizing the knowledge about the internals of FILE. The file abstraction in C is not IMHO not different from a file abstraction by a separate file class, in C the smallest sensible testable unit for a file is the data type FILE together with its operations. So I don't see how writing unit tests for an equivalent File class (like the File classes in Java or C#) should be quite different from writing unit tests for file operations in C.
Jun 19, 2017 at 22:34 history edited user275704 CC BY-SA 3.0
grammar
Jun 19, 2017 at 19:56 history answered user275704 CC BY-SA 3.0