Re^6: To parens or not parens in chained method calls

:P I throw down as many tests as I can think of as soon as they occur to me and extend whenever I notice a change or something I missed, which means I break best practices and cause duplication and such too often.

Computer is my hand-servant though. I’m not concerned about overworking it despite knowing I could write tests more intelligently and strategically. I’ve rarely come to regret writing too many tests though and I have often regretted writing too few.

Comment on Re^6: To parens or not parens in chained method calls

Replies are listed 'Best First'.
Re^7: To parens or not parens in chained method calls by stevieb (Canon) on Feb 16, 2017 at 23:13 UTC
In a case where I know that I'm doing things I shouldn't within tests (eg: periodically I'll peek into my objects innards to ensure what's supposed to be there is there, and that a getter is in fact looking at the right thing) and am about to make a change that I know will break numerous tests, I assess at a high-level which tests I expect to break, fix them one at a time, ensuring that each fix is the correct one, and I'm not changing something that broke unexpectedly. I would rather update 30 tests across 10 files in these types of cases than not have enough tests to tell me that I've broken something that will be found later. Another benefit of writing tests I find, is that it allows me to understand the philosophy of design decisions in ways I may not have thought of originally, due to the nature of throwing crap at things. Sometimes in early stages of a new project, my tests will dictate that the API needs modifications. Not only that, but I often don't write example scripts to test my code; I just begin each sub by starting a new test file for it (typically). That's usually my example script.	[reply]

Replies are listed 'Best First'.

Re^7: To parens or not parens in chained method calls
by stevieb (Canon) on Feb 16, 2017 at 23:13 UTC

In a case where I know that I'm doing things I shouldn't within tests (eg: periodically I'll peek into my objects innards to ensure what's supposed to be there is there, and that a getter is in fact looking at the right thing) and am about to make a change that I know will break numerous tests, I assess at a high-level which tests I expect to break, fix them one at a time, ensuring that each fix is the correct one, and I'm not changing something that broke unexpectedly.

I would rather update 30 tests across 10 files in these types of cases than not have enough tests to tell me that I've broken something that will be found later.

Another benefit of writing tests I find, is that it allows me to understand the philosophy of design decisions in ways I may not have thought of originally, due to the nature of throwing crap at things. Sometimes in early stages of a new project, my tests will dictate that the API needs modifications. Not only that, but I often don't write example scripts to test my code; I just begin each sub by starting a new test file for it (typically). That's usually my example script.

[reply]