@Donald.McLean If I could ask for some of your time - what do you think the benefits of pair programming are? I do a lot of front-end web stuff and I don't like the whole idea of someone looking over my shoulder while coding. It's not a pride thing, but more of a "someone is breathing down my neck" thing.

@ARedHerring So that's why you should buy a lumber company aswell

@MikeEdenfield I feel that might just be an impossible thing to do in a lot of cases

it's hard to break a mindset that's already ingrained.

"why should we do automated tests? what we've done up until now works fine...."

@ARedHerring He should be sitting next to you, not standing behind you ;)

@ARedHerring we have been able to do that for new projects. The devs who started working here after we decided to to automated tests and unit testing don't know any different.

but yes, trying to go back and retrofit good testing methodology into a legacy project with legacy devs is mostly a lost cause.

@CaptainObvious This is my submission to the community challenge. It's pretty OOP based, so I'd welcome people giving answers about the way I handled that even if Python looks like a hot mess to you.

@MikeEdenfield do you have any resources for the training on unit testing you've done with your employees?

Okay, I should be serious again... How can you handle having the feeling that you wasted time when doing automated tests?

@MikeEdenfield oh yes... painfully so.

@skiwi Wait until you make a Big Change (tm)

@ARedHerring If you're feeling that, then you're doing it wrong. Pair programming is more about the constant dialog between you and your partner than anything else. And the keyboard should pass back and forth frequently.

Then be glad that your code still works.

@ARedHerring unfortunately we don't have the $$ for any kind of formal training, but I can recommend some good books.

@MikeEdenfield I'd appreciate that

training mostly consists of me and the other 2 senior devs reading, learning, and then doing lunch & learns.

waaaiit... there's formal training for writing automated tests???

Oh, I well do understand the reasons of automated tests myself, but doesn't mean I always use them

@skiwi so sadly true...

@skiwi Here's one. Let's say you're making a web app. And suddenly someone comes along and says: oops, fooing the bar doesn't work on X model Y version

But maybe I don't always stay sane with regards to how many tests are actually needed

(and this happens a LOT when you have to support IE, Chrome, and FF)

With a test (not necessarily unit level) you can isolate the problem and be sure it never happens again

@ARedHerring ermph... shouldn' t really be the case...

@ARedHerring for basic unit testing, we have mostly followed the advice from amazon.com/The-Art-Unit-Testing-examples/dp/1617290890

@Vogel612 IE9+ -> IE11

oh okay that's different...

Perhaps we should take the discussion about running an organisation to a different chat room? There's a lot of discussion going on here about two different topics and its getting hard to follow

@ARedHerring Also, pairing isn't for everyone - but sometimes resistance to it is just ego. A good pair is the ultimate team.

I can follow multiple discussions easily enough :)

@ARedHerring I'd say that conversation is preeeeetty close to the core values of Code Review

@Donald.McLean I don't think it's about my ego, I don't consinder myself to be better/worse/above anyone. I just find from the sound of pair programming, it might be counter to "my style". That said I've never done pair programming, so I wouldn't know.

@Skiwi I'm not debating the on-topicness, but I worry if it's becoming a Big Conversation (tm) :P

@ARedHerring mostly though it's the stuff you already said. Everyone knows the basics of good dev practice: source control, automated builds, automated tests, documentation. You just have to make them a built-in part of your process. Schedule time for them in every sprint for every feature.

for us it took a few false starts to get unit testing and automated testing "right" but you just keep learning

@ARedHerring Have you ever sat with someone and brainstormed?

@ARedHerring A dedicated coder.

@MikeEdenfield I never feel like I have the hand of it. I always feel I'm Doing It Wrong or not writing enough tests. Or I'm testing the wrong thing.

@Donald.McLean Not for the longest time. I've been the sole coder in all 3 positions so far on my project

@ARedHerring that is one thing that it took us a long time to get used to. You probably aren't writing enough tests, and you're probably doing too much in each one. Tests aren't production code so they're not supposed to follow "good coding practices". Don't hesitate to cut and paste your butt off.

@ARedHerring Not necessarily in a software context. It could be brainstorming ideas for a party, or dinner.

@ARedHerring but it's also a trade-off... you write as many unit tests as you have time to write without missing a deadline and losing the business. so you kinda get a feel for what parts of the code are "highly unlikely" to break. and you often get it wrong and just deal :)

@MikeEdenfield If you have time, here's a repo I put up a few days ago where I feel I haven't written enough tests. The idea of the repo is simply to run off to an API, and check if the results have one field equal to a certain value.

okay... this is getting really lengthy: calling mandelbrot and tdd to move to separate rooms!

@Donald.McLean party or dinner? I am not a social animal. :P In all seriousness, I haven't brainstormed since I was in school, so that's at least 3-4 years ago.

@rolfl Nifty. Is that multithreaded?

@Vogel612 But if they move to another room, what am I supposed to watch then? ;)

@skiwi paint dry

@ARedHerring 3-4 years? That's practically yesterday. I'm 52.

@EBrown Yes.

@Donald.McLean I'm 20. ¯\_(ツ)_/¯

@ARedHerring I don't have a lot of time right now but.. a very quick top-of-my-head impression: no negative unit tests?

The problem is that if you move both conversations to the same (alternate) room, all you've done is sidestepped. ;)

Edge cases that you expect to fail? I dunno enough about the API to know if that's even an issue.

but you're testing that "if I give the right input I get the right output". That's the easy case :)

@ARedHerring My point is that for any project with more than one person, it is all about teamwork. And being a "social animal" or not is irrelevant. You have to buckle down and learn to work together, and pair programming is one of the best ways to do that.

@MikeEdenfield No, I didn't write any of those. Perhaps that would have been a good start. I don't do much defensive programming which is an error

← 54 messages moved from The 2nd Monitor

← 6 messages moved from The 2nd Monitor

Thanks @Vogel612

@ARedHerring Generating negative unit tests is always a hard problem for me.

because any edge-cases I can think of to unit test I already thought of in my code. :)

I don't think it's a 'hard problem' for me

there are expected edge cases when I talk to that API

I just didn't implement them because lazy

for as simple as that API is, I think there aren't going to be a ton of tests.

and 90% of them will be negative tests, which is usually the case.

hey

so you're only really gonna get one or two good positive tests, if there isn't much variety in the inputs to each function

I do think I should have moved the logic of one of the functions out to another file

because right now that logic is stuck there in with the logic for gathering the data as well so it's only testable in integration

yeah I saw that.

I'm not sure what kinda mocking frameworks you have available to you, but if you can mock up the other API calls you could still test that a bit.

but it is getting into an integration-level test

nock is a mocking framework (which mocks the API call)

One thing I have never managed to get my head around is actual, "pure" TDD.

I only tend to do that with bug fixes.

for new development, my initial design ideas always morph into production code before I can stop myself :\

@MikeEdenfield TDD can really force you to think through the design of you API in a way that just writing it does not. Especially edge cases.

I know I should be doing it.

Off to run some errands. I'll be back online in a couple of hours.

@MikeEdenfield I've done almost pure TDD just once.

What I did was create my core classes and interfaces so I could use Intellisense and use the right names and stuff.

Then, I wrote a bunch of tests, but I didn't run them.

After I implemented the feature, I went back and adjusted the tests to account for any write-time issues I found, then I ran the tests and fixed more bugs in the tests and code.

my major stumbling block with TDD is that I develop stuff very iteratively in the IDE. I just do a prototype/POC and let it evolve into the final product without really stopping to document how it should look when it's done.

I usually write like that too.

I need to take a break in the middee there, once I have the prototype or POC done, and think how it's going to look and write tests against it right then

i just get on a roll

Me too. I usually write the code, then the tests.

But, I have a lot of school to do, I've got to go.

And #2 is that I'm not 100% convinced in my own head that TDD is going to be a dramatic improvement over what we're doing now, and it's too radical a change for me to make on my own and "find out".

I have no confidence that I could get my time estimates right.

I'm waiting for a project that I have some leeway with the scheduling to try and do it right.

I do believe that's my cue to leave for the evening :)

and so, I shall say monknight @all

Just recently I "got on a roll" and implemented a new feature without any unit tests. Of course it was badly broken and wasn't sure why until I implemented the unit tests and could test that part in isolation from the rest of the app.