I am a big believer in unit tests, but don't like TDD much. I think it fosters the belief that you can test quality into a product. Testing should be a verification that the rest of your process has resulted in a high quality product. It shouldn't be the means of getting quality into the product.
TDD isn't about fostering the belief that you can test quality into a product. It's just a way of focusing your mind and ensuring your code gets run as early and often as possible so bugs are caught earlier.
FWIW, most people shouldn't be unit testing at all. They should be writing high level automated integration tests.
Hmm sorry, I've never heard of TDD guaranteeing quality of a product. It _might_ mean you've delivered what's been asked of you (along with acceptance testing) but quality? Far from it. And if you're unit testing _after_ the fact, then you're just asking for trouble.
I'm in the same boat. TDD might be suited for some narrow cases of development workflows. However, it doesn't do too well for others, and completely poorly for a vast category of things. Overall, if your Sprint defines good unit test coverage as criterion for "Dev Complete" it's more than sufficient.
>I'm in the same boat. TDD might be suited for some narrow cases of development workflows. However, it doesn't do too well for others, and completely poorly for a vast category of things.
I find where it works poorly it tends to just mean you have poor testing tools at your disposal.
Plus, people have a tendency to test things at far too low a level.
He's on sort of the right track but I don't believe this is true at all:
"Some have seen this solution to the shallow test problem and suggested that the ideal scope for our tests to target is the user interface, and to execute all the code in each test including framework and external components like the UI and the database.
Unfortunately the RoI of system testing is too low to do much of this. They’re slow, they’re brittle, they require careful environment setup and teardown, and they’re much more difficult to write and maintain than unit tests."
Slow is okay. It's better to be realistic than fast. You can also throw computing power (which is cheap) at slow. You can't throw computing power at unrealistic.
Brittle means either you have bugs which your test helpfully uncovered for you (e.g. race conditions) or you wrote a buggy test.
"Moreover, testing through the UI for every scenario in your code is just unnecessary"
It's almost always better to loosely couple your tests. It makes it easier to refactor the code that they test.
One nice advantage of TDD is that you don't risk building a hard to test product. Of course, you have to pay attention to what you are testing and make your test cases meaningful.
One of the problems I've seen ith TDD is that the team decides on a metric of minimum code coverage of x%. Now, in order to achieve x, a large number of basically useless tests end up being written simply for the sake of getting the coverage number up regardless of how poorly thought out those tests are.
That's not an inherent fault of TDD, of course. My point is that the mindset that seems to follow it leads to dumb things like that happening.
I believe TDD is not the only methodology where unit tests are allowed.
As far as I know, TDD suggests that the software is planned and driven by many failing test that are coded initially. A cautious developer may prefer building a feature on top of a failed (later to be satisfied) test but we worry that documenting the target product with all the necessary server and client tests may consume too much time initially. Some features that are likely to be postponed for later releases should not allocate our precious time and in the beginning, we may lack necessary wisdom to foresee it.
The other worry is that TDD in its most basic form is still a coding framework which may leave less freedom for the developer to express his/her preferred productive approach. We prefer to apply a framework on how we communicate, keep track of changes and measure our performance. The rest is left for the developer to experiment and find the most effective style for herself.
Assuming they have a solid and reasonable argument against it and not just hand-waving and throwing toys out of the pram :-) . In which case, if they do, I would love to see it.
> I do not like broccoli. And I haven't liked it since I was a little kid and my mother made me eat it. And I'm President of the United States and I'm not going to eat any more broccoli.
Some people just don't like broccoli. You can force them to eat it, but they'll end up resenting you.
The burden of proof usually lies on the person suggesting a change to an existing process. What arguments would you give to try to convince someone to do TDD? Because arguments against can be really simple and reasonable: "it's a risky change that will slow us down without obvious upsides", "we don't like to change, it's effortful, and stressful", "we don't have the skills to do it" etc. And that can be told of ANY change of any process/routine!
So what would you say to a team of developers if you wanted to persuade them to do TDD? (or to a manager who has influence on them)
>The burden of proof usually lies on the person suggesting a change to an existing process. What arguments would you give to try to convince someone to do TDD?
Arguments don't work. You need to build the tools that let your developers actually write sensible tests (i.e. tests which mimic user stories).
Once the tools are there the process becomes fairly natural and the upsides become obvious.
Some people call this BDD. It doesn't really matter what it's called, but it's generally a faster and less risky approach to programming.
It leads to lots of brittle and highly coupled tests?
It always focuses on the next immediate task which leads to going down a lot of dead ends, and a lot of local optimums that need to be refactored out?
The key benefit is that it helps you focus, even when tired or stressed. You get dozens of small wins/celebrations every hour which is great for your motivation. It also ensures you actually write tests (again handy with tight deadlines and high stress situations).
Does that make it worthwhile? Sometimes. I did a TDD exclusively when I had young kids and it was a great help with my focus. I'd recommend it to new parents, people with sleeping disorders, people in high stress work places, etc.
Our goal is to integrate your docker workflow very tightly with github. The user will be able to decide which features to switch on and off and whether to write or only read! Obviously we'd rather announce these features when they're ready and we'd rather collect the data upfront so we don't have to prompt the user once again when they sign in.
That seems like an OAuth anti pattern. Why would you ask the user for every permission when they're signing up? That can only hurt conversions. Ask for the bare minimum, and then request more permissions if the user does something within the app that needs them. Especially for something as sensitive as this, you want people to feel safe using the product and you can't do that by scaring them when they hit "Sign Up with GitHub."
I do agree that's something we might have to change if the signups slow down. And we need to do a cost-benefit on that perhaps. At the moment, folks are signing up though :)
Which perhaps shows how little "folks" care about who they share their data with. Additionally I have private organisation repos that I really don't want you taking a peek at. Sorry, no dice for me unless this is tightened up.
You're right. We received more than a few brickbats for this since yesterday. So we changed the github oauth request scope. As it stands now, the data we request is only the user scope which includes the user's private email address (https://developer.github.com/v3/oauth/#scopes). We'll add additional scope requests if a user elects to use our upcoming github build feature.
