开云体育

Empty out the integration and up tests and sub in more microtests. [testdrivendevelopment] <testdrivendevelopment@...> wrote:

http://martinfowler.com/articles/continuousIntegration.html Jump to the section: "Keep the Build Fast". -- Abra?os, Josué http://twitter.com/josuesantos

A common approach is to split your tests by type (unit, integration, UI), or at least by speed (fast, slow). Then, always run the fast tests before check-in, but let the build/CI server run the slow

Hi, I'd say you have a good opportunity for refacoring! If your tests cover your functionality; go a head and refactor into smaller functional units. good luck! /niklasb <-----Ursprungligt

I don't know if it still works this way, but the Flex framework used to run a dedicated nightly build for the UI tests that could take a really long time to run. They had their own Jenkins build

It might well depend on the size and complexity of the system. I agree that ten minutes is long, but… on a system with several million lines of code and and tends of thousands of unit tests, it

25 minutes is ridiculously long. The old XP rule was 10 minutes and that was with 90s hardware. I start to get annoyed when it takes more than a few seconds. Likely the problem is too many of the

We use?https://rubygems.org/gems/parallel_tests?. ?Be sure not to run more parallel test processes than you have CPU cores available, or the tests won't run as fast as they can. -- Albert Davidson

Hello, To those who have experienced test suites that run long, say ~25 minutes, what are some techniques you have used to mitigate it? We still would like to be able to check in often and run the

There's always Growing Object Oriented Software Guided By Tests by Steve Freeman and Nat Pryce if you want to know more about the mockist approach. testdrivendevelopment@...> wrote:

Yes， I'v read TDD by example. And now I'm reading the second. Thanks for the advice. :)

Keith, Thanks for the reply. But I'm not working on C or CPP now. :)

Yup, I'v read it. Nice of you! Thanks. :)

If you're using C or C++ I recommend James Grenning 's book on "Embedded TDD" C. Keith Ray http://agilesolutionspace.blogspot.com/ twitter: @ckeithray

[testdrivendevelopment] <testdrivendevelopment@...> wrote: I recommend you to read the following two books: * TDD by example - Kent Beck. * Growing Object Oriented Software Guided by Tests

Sailor - read the book Test Driven Development: By Example by Kent Beck. br niklasb <-----Ursprungligt Meddelande-----> From: sailor.gao@... [testdrivendevelopment]

Thanks for reply. Nice of you. Actually I don't know how to write the test cases ( step by step using TDD). I know we should code by interface not implemention and we should consider the requirement

Thank you, Surya! You are very nice. And the answer is so helpful. I'll try it. :)

Sailor, If you have a good mocking tool it’s very little effort to create a mock object. Then you can make assertions such as which methods should be called, and in what order. (For example

Here is the a list of possible tests for the UserService.Record method: ? Record__UserWithSameNameAlreadyExists__DeleteTheUser // Asserts only on calling the method _userDao.Delete with appropriate