- Unit testing (Re: Putting project code in many different files) - 5 Updates
- TDD considered harmful - 1 Update
| Ian Collins <ian-news@hotmail.com>: Feb 03 09:50AM +1300 Jerry Stuckle wrote: > It sounds complicated, but really isn't. You have a start repo, a > development repo, a test repo and a production repo. Code is only > changed on the development repo and testing on the test repo. There were a couple of novel concepts invented way back in the history of SCM tools called "tags" and "branches". Read up on them, you'll learn something. -- Ian Collins |
| Ian Collins <ian-news@hotmail.com>: Feb 03 09:57AM +1300 Jerry Stuckle wrote: > create the code for testing, ensure good input is processed properly and > invalid input rejected. You need to duplicate error conditions, some of > which can terminate the test - and finally, evaluate the results. There is software to do all of the donkey work known as unit test frameworks. Read up on them and you might learn something. -- Ian Collins |
| Gareth Owen <gwowen@gmail.com>: Feb 02 09:33PM >> Chapter 11 bankruptcy is the gift that keeps giving. > I don't see YOU being worth a few billion dollars. My father didn't leave me a few million dollars. > But then trolls, when they can't refute facts, have to resort to ad > hominem attacks. Except it didn't work in this case. Sick burn, Don. |
| "Öö Tiib" <ootiib@hot.ee>: Feb 02 02:07PM -0800 On Tuesday, 2 February 2016 22:27:34 UTC+2, Jerry Stuckle wrote: > tested. You should have a testing system (actually, often times more > than one) with code that has not been thoroughly tested. This system > would also have the tests and test results. Not the production repo. We did not talk about test systems/farms/clouds and sizes of those. I did talk about pushing changes into shared workspace of team, IOW common repo of team. > Otherwise things can easily be missed. Even service packs should be > kept in separate repos to prevent accidental contamination with the > original code. What contamination? Full repo helps me to see commit notes (typically containing issue ID) and author's name of change-set that added or edited a piece of code that I'm in doubt about for whatever reason. That does contaminate nothing. What repo does somehow migrate code or other files between branches or up and down of revisions and tags and contaminates something? > tests, to a final service pack repo. When you're done, the service pack > repo contains all the files for that service pack - and only the files > for that service pack. Those "move"ments sound like between hard-drive folders and not repos. In repos that I have seen changes done in one branch are sometimes "merge"d to other branch. Usually there is certain process for that. Files that are needed for nothing in a branch are simply erased. > Having separate repos like this allows for backup/archiving of code as > it was shipped as well as code currently being worked on. Backups are orthogonal and I am unsure what these have to do with any of it. > It sounds complicated, but really isn't. You have a start repo, a > development repo, a test repo and a production repo. Code is only > changed on the development repo and testing on the test repo. People work across continents providing their changes to same repo. They indeed can have their own local copy of that repo on what they work in separation before they push their changesets or provide their patches for common repo between teams or organizations but I have nowhere seen that files are moved between repos like you describe. |
| Ian Collins <ian-news@hotmail.com>: Feb 03 11:20AM +1300 嘱 Tiib wrote: > they work in separation before they push their changesets or provide > their patches for common repo between teams or organizations but I > have nowhere seen that files are moved between repos like you describe. I doubt that you ever will. He's making stuff up as usual. -- Ian Collins |
| Ian Collins <ian-news@hotmail.com>: Feb 03 10:05AM +1300 Mr Flibble wrote: > when you are using TDD you are stumbling along fixing failing test cases > without designing anything. TDD results in an incoherent mess that > cannot be called "design" by any stretch of the imagination. Have you read https://blog.8thlight.com/uncle-bob/2014/05/02/ProfessionalismAndTDD.html and the paper it links? I've yet to see any of my colleagues "stumbling along fixing failing test cases", they all know hoe to use TDD well. Have you ever worked on a team that uses it? Given what you have written thus far, that question is probably rhetorical. -- Ian Collins |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment