开云体育

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 test suites prior to checking our code in to our repository but these long running tests makes us stretch what we mean with "often". Joen

Sailor.gao, your question is not very clear. I suppose you want to know if method Record actually calls GetUser then Delete or Save? So, either you reason by the side effects (such as the record has gone from the database), or you use a mock of some kind to show you call the expected methods in the expected order. John D. Sent: 25 April 2016 14:37 To: testdrivendevelopment@... Subject: [TDD] How to use TDD to test a process? I try to use stub but it seems not very good. I want to know how should I write the test case, and how many should it be? Could someone help me? Thank U! logic like this: public class User { public int ID { get;set; } public String Name { get;set; } public String BrokerID { get;set; } public String Timestamp { get;set; } } public interface IUserDao { User GetUser(string userID,string brokerID); bool Save(User user); bool Delete(User user); } public UserService { private IUserDao _userDao; public UserService(IUserDao userDao) { _userDao=userDao; } public bool Record(User user) { User origin=_userDao.GetUser(user.Name,user.BrokerID); if(orign) { if(!_userDao.Delete(origin)) { return false; } } if(!_userDao.Save(user)) { return false; } ; return true; } }

I try to use stub but it seems not very good. I want to know how should I write the test case, and how many should it be? Could someone help me? Thank U! logic like this: public class User { public int ID { get;set; } public String Name { get;set; } public String BrokerID { get;set; } public String Timestamp { get;set; } } public interface IUserDao { User GetUser(string userID,string brokerID); bool Save(User user); bool Delete(User user); } public UserService { private IUserDao _userDao; public UserService(IUserDao userDao) { _userDao=userDao; } public bool Record(User user) { User origin=_userDao.GetUser(user.Name,user.BrokerID); if(orign) { if(!_userDao.Delete(origin)) { return false; } } if(!_userDao.Save(user)) { return false; } return true; } }

My google searches are giving me bad results... :( Does anyone know of any good articles, or have any good hints, on how to do TDD for writing PostgresSQL, or database code? I need to write a custom system which allows us to do DB migrations and updates etc, a bit similar to what Ruby on Rails with has their DB rake:migration command.* Google is mostly giving me information on how to abstract out DB objects, but I need to verify that my new custom migration system is actually working. The tests I would want to write are simples 1. Confirm that a migration file worked (say by adding a column) 2. Confirm that only the latest migration was run, and not a previous one (say by checking a value in the table wasn't changed) I appreciate the help you can provide. *The short version is: 1. A command which generates a .sql file with a timestamp in the file name. 2. A command which checks all the files in a folder, and then does some comparisons to another db, and picks one or more .sql files to run on the db in question.

Are you talking about test driving database access code from a general purpose language? Or are you talking about test driving stuff inside the database engine? There is http://pgtap.org/ but I would look for a way to do it at a higher level, unless... a gun was pointed at my head.

This may not seem like a real answer. Save it and come back after all else fails. Forget about all that stuff and start doing TDD. Do it by yourself. Do it with a partner if you can. Stop trying to make anybody else do anything. You seem to be describing a situation in which neither the docs nor the manager want to use TDD, so focus on what you can control. Maybe in six months someone will ask you about what you are doing that makes your code so good. Charlie

TDD in Node.js is not substantially different than TDD in any other language. There are a dizzying array of frameworks to choose from. I have a strong preference for Jasmine as the test framework, particularly in CoffeeScript. If you add the browser to the mix things get complicated, particularly if you are trying to test in the browser or test code you expect to manipulate the DOM in specific ways. But, server side is exactly the same as any other language, and any old TDD book/tutorial will put you in the right direction.

James Shore has an extensive video course on the subject: http://www.letscodejavascript.com/

Hi there, A short answer: Patience, love, and understanding, fostered by someone who's been there/done that. Do you have any TDD-experienced folks in the team who can work with your senior dev? A primary goal when I start pairing with devs is help them out with their current challenges, by showing them useful legacy code techniques to start getting their code under control and by helping them figure out other problems and coming up with better solutions (the primary goal of pairing). Sitting with them allows me to start working in test-first as we go along, talking about techniques, values, etc. as we go. This is effective for most devs, including senior ones. (I had one lead dev tell me "I've learned more in the past two weeks than in the past two years.") The legacy themes and techniques quickly demonstrate how it's possible to make changes and minimize fear. As far as the dip in productivity, it's not hard to get someone to agree that it makes logical sense and is worth the initial dip in productivity. On one simple score, most shops don't quantify a cost to develop a given feature, since they don't take into the account the cost of rework, the additional cost to understand poor code, and the true costs of defects. Regards, Jeff Langr Software Solutions, Inc. http://langrsoft.com Pragmatic Unit Testing in Java (http://pragprog.com/book/utj2) Modern C++ Programming with TDD (http://pragprog.com/book/lotdd) Agile in a Flash (http://pragprog.com/book/olag) Agile Java: Crafting Code with Test-Driven Development (http://www.amazon.com/dp/0131482394) Essential Java Style (http://www.amazon.com/dp/0130850861)

HI, I am anticipating following challenges in TDD adoption. Any suggestion how to deal with such situations? The list is long :-). Thanks, 1. You have a very experienced, senior andtechnically sound developer who has designed and developed solutions in atraditional way. This person has not completely bought in to the idea of TDD.How will you motivate such people? 2. The program that you are working on is complex,for that matter every program is complex, has dependencies on other systems/program/modules/components,how and where do you start with TDD? Developer fear making change/refactor as they believe any such attempt can break existing working system. They don't want to mess with something that is working. 3. Your team has traditionally worked in a testafter situation, first write code and then write unit test cases. Time andagain their mind first think of implementation logic since it has been trainedthat way for a long time, how do you make them unlearn this habit? 4. TDD will take time initially. The estimation of yourproject was done when TDD was not in picture. Now that you have to use TDD, how would you now negotiate withyour manager and business for this extra time? 5. Why is singleton not considered a good designpattern. what are Technical challenges in using TDD in web applications. W An

Following the previous Java thread, I'm looking for recommended and updated sources (tutorials/books/courses/etc) on TDDing javascript applications, mainly server side. Thanks, R.

A BIG thanks to all who responded to my earlier post. During our discussion, we had this topic on TDD/Junit antipatterns. We did a bit of study and research on our own and are looking for examples that can explain the TDD/Junit antipatetrms better. This is one of the precautionary thing we want to follow. Any resources / pointers will be of great help. Thanks, Pooja

It's been 10+ years of TDD, so people have had similar questions in the past. Search and you shall find :) http://stackoverflow.com/questions/333682

It really really helps to have a coach working with your team and its code. C. Keith Ray http://agilesolutionspace.blogspot.com/ twitter: @ckeithray

Al makes a good point, although I wouldn’t say, “orders of magnitude more difficult.” You are going to spend a lot of time writing tests for code that already exists and then having to break that code in order to make it testable. This is not exactly TDD. In fact, it is the problem that TDD was designed to solve. It is good advice to spend a little time test-driving new code to get your feet wet, especially for programmers who are less experienced overall. Additionally, 1. Focus on getting something wrapped in a test and then refactoring under test until you have a good solid OO design within the boundary of the test. It will feel like you are refactoring way too much at first, but pushing all the way to the boundary is the only chance you have to make the design better rather than just not worse. 2. Get in the habit of treating every test failure in integration as an emergency. Don’t succumb to the temptation to treat intermittent failures as normal. It will undermine the culture of quality and rapid feedback that you are trying to build. 3. It is really hard to overstate the value of pair programming and continuous integration in this context. These practices are very synergistic, and you will get better results faster if you do them together.

TDD with existing non-TDD'ed code often is actually WELC (Working Effectively with Legacy Code, see the book of that title by Michael Feathers), which is orders of magnitude more difficult. I advise you to start TDD with net-new code. It could be new methods within existing classes, if you don't have any truly greenfield areas of code to work on. Al

HI, We have recently started using TDD. We have gone through the training, learned some of the TDD good practices/challenges, using junit, mockito tools/framework etc. Since its an early start to the journey, I would be glad to hear some practical advice from folks here, some of the DOs and Dont's, tips and tricks etc. We are going to have a bumpy ride, especially with exisitng code, so it will really help if we can hear from experinced people. Thanks, pooja

I have to shake my head that the need for TDD still isn't better understood. I guess the current generation has been living their whole life where "Nothing ever works", that they see no need to ensure that it does, actually indeed work. I'm glad to see that at least there is agreement that tests are needed at some point, but they still don't seem to get that TDD is the only way to have confirmation as to what areas of your code needs testing. brought to you by the letters A, V, and I and the number 47

For Knowledge http://www.infoq.com/news/2016/03/tdd

Avi - nice to see you're still out there :-) I've played around a bit with Unity and took the weak position vis-à-vis TDD. That is: the visual interface is tested by looking at it and the rest is just normal C# code with normal tests. John D.