开云体育

I will recommend pitest for Java mutation test. Sent: Friday, October 19, 2012 9:30 AM To: testdrivendevelopment@... Subject: Re: [TDD] Test Coverage Tool covertura is not bad 2012?

covertura is not bad 2012? 10? 19? ???? Adam Sroka?? ??:

Lots of good leads here (in several languages): http://en.wikipedia.org/wiki/Mutation_testing [Non-text portions of this message have been removed]

Is that agitar?

Yeah, that's it. Mutation testing. thanks From: testdrivendevelopment@... [mailto:testdrivendevelopment@...] On Behalf Of George Dinwiddie Sent: Thursday, October 18, 2012 2:15

Amir, That sounds like mutation testing. I think the phrase "without test coverage" is misleading, here. - George

There exists a tool that looks at the code, changes the direction of conditionals, the value of constants, etc. This should result with failing tests. It ensures that someone did not write code

Amir, It's not clear to me what you seek. A code coverage tool (such as Emma, for java) would tell you if code was executed during the test run. A mutation test tool (such as Jester, for java) would

I remember there exists a tool that will modify existing code to check whether that code has coverage or not. I can't remember its name. Can someone help my failing memory there? Thanks, A.

The 14th International Conference on Agile Software Development is a leading conference on agile methods in software and information systems development. XP2013 will be located in Vienna, Austria.

We are conducting some research into automated regression testing practices in industry, and as part of this research we have created a survey questionnaire for which we are seeking respondents. I

We split a class last week. We used the recipe in Refactoring. We ran the tests after just about every step (search and replace is only one step if you squint right). It worked. -- Tim Ottinger, Sr.

The only thing you are getting wrong is that Nayan was being sarcastic in the response - talking about the "old way" of doing things (usually in waterfall/waterfail). Have a nice weekend. :)

But the whole idea around TDD is the concept of "emergent design", where you don't have the full requirements and you don't do a "big design up-front", but rather you start with one simple example and

Thanks. I'm not sure I follow you completely, but that's maybe because I wasn't very clear, as your last question implies. So to be more clear, I'll explain a bit further and will try to give an

Hi Arnon, [snip]

--- "arnonaxelrod" <arnonaxelrod@...> wrote: I don't adhere to the mistaken belief that "xUnit" tests have anything to do with *UNIT* testing, and should be limited to testing one class at a time. If

When you think that the one class has two responsibilities it makes sense to split it. If you did that first you'd have two classes with one test, and that test would be testing both responsibilities.

It's a refactoring question, but what the heck? Alternative path: Start by creating A2, which inherits everything from A (classes essentially identical other than access permissions). Make A's private

I think you might be over-thinking this. I would probably just refactor the class using the existing tests. I don't see the need to modify the tests themselves until you discover a value in changing