1,193 reputation
512
bio website madcoderspeak.blogspot.com
location Mumbai, India
age 33
visits member for 3 years, 4 months
seen May 17 at 3:44

Developer - I like to build things and see them work. Gimme a good book or a game and I can keep myself out of trouble. Got hooked on TDD-XP-Agile around 2005.. trying to get to the promised land since. Work with C Based languages. Play with Ruby.


Dec
23
comment Does not testing internals entail diligent refactoring and/or rely on developer talent?
@MakeMinePanacea - Ok. I think I see your dilemma : my tests are "specs" ; they are not implementation dependent. e.g. If I want a method that sorts, I write a test that feeds in input data sets and verifies output sets. My test would not be different if I satisfied the spec by implementing BubbleSort or MergeSort. Corner-cases can be tested by passing in different input-sets that would cause the internal code to be executed. If you can post such an example, maybe I can reword it OR I end up learning something new. HTH
Sep
29
comment Offensive programming / coding
Funny term - I can think of a few lines I've read in the comments section. Not sure if it relates to defensive programming.
Jul
5
comment i am “scared” to learn a new language
Another way to look at it would be .. what if I'm better at it than C# ? No easy way to answer it apart from just giving it a good try. You don't stand to lose in any case.
Jul
4
comment Automated Testing: Explaining its Business Value
@orangepips - My objection was related to the QA/Dev Exceptions/Happy divide. Unit tests exist to ensure that you're building it right. QA/Acceptance tests exist to ensure that you're building the right system. So all scenarios that are relevant to the business (e.g. the credit card has expired) should be tested by QA before they brand it ready to ship. I recommend automation of acceptance tests - Automate the tedious, routine stuff 80%+. Top that off with some imaginative non-scripted manual testing.
Jul
1
comment Automated Testing: Explaining its Business Value
@orangepips - I disagree. "QA level"/Acceptance tests should test everything that matters to the user.. i.e. happy paths and alternate scenarios. Unit tests frequently use mocks, stubs and fakes... which means there is a possibility that the happy path unit test passes but when all the components are brought together, the happy path end-to-end test may fail. It is too much of a chance to be left to fate.
Jun
25
comment TDD vs. Productivity
@lurscher - it depends. Usually it is 50% Reflection followed by one of 1. Comment the current failing test and go for some (p)refactoring to be able to write the next test. 2. Go hit the whiteboard. Draw the main classes and see if there is a misalignment of responsibilities or new types that need to surface. 3. Ask for help on the TDD mailing list. 4. Take a break.. and return with a fresh mind.
Jun
24
comment TDD vs. Productivity
@asgeo - can't edit that comment.. the link has picked up a trailing bracket.This should work - goo.gl/dWp3k
Jun
22
comment TDD vs. Productivity
@Nairoi - Not sure what test runner you are using. I just learned a name for what I wanted to convey. Abstract fixture pattern[goo.gl/dWp3k]. This still requires you to write as many Fixtures as there are concrete SUT types. If you want to be even more concise, look at your runner's docs. e.g. NUnit supports Parameterized and Generic test fixtures (now that I searched for it) goo.gl/c1eEQ Seems like the very thing you need.
Jun
22
comment Do you write unit tests for all the time in TDD?
@mcaa - Whatever Steve said + you might set a precedent that it's okay to not write tests. The threshold of what is "interesting enough to test" might keep rising over time... The test above is not much of an effort.. it's hardly 5 lines and in return you get 95%+ peace of mind
Jun
22
comment Do you write unit tests for all the time in TDD?
@Yes - it tests that check() is wired correctly. There should be another test that Service.Check() works once it receives the call. This test looks trivial today but as time goes on someone might add more code to this method (e.g. a guard clause if some-condition return;) and break existing behavior. This test safe-guards against that.
Jun
16
comment Should the test and the fix be written by different people?
@Rein - it isn't mandated.. but in general it works better when guided by Acceptance tests.. especially to maturing teams.
Jun
9
comment Code formatting : Laying out functions based on call hierarchy within a class file?
I'm not advocating large classes with regions added to mask the smell. Not trying to get religious.. but having a consistent layout within a project speeds up things -- knowing where to look. Grouping bu visibility as the added benefit of having the public API close together so that you can find your specific entry point and drill down from there...
Jun
9
comment Code formatting : Laying out functions based on call hierarchy within a class file?
@ryanc - the prelude to that paragraph emphasizes that "closely-related/cohesive" concepts should be vertically close together [Prevents scrolling around when you're trying to figure something out]. The called functions are laid out beneath the caller in order of calls. See added code-snippet
Jun
9
comment Code formatting : Laying out functions based on call hierarchy within a class file?
@Neil - I'm trying to judge the merit of the advice.. irrespective of the source. @ John - and the tip is the opposite of forward declarations.. you put the caller first .. the 'callee's are declared just below the callers.
Jun
9
comment Code formatting : Laying out functions based on call hierarchy within a class file?
Yes but that would imply all the public functions should float to the top of the file as one group viz. conventional approach. The proposed approach is different (or at least how I read it).. see update in question
Jun
2
comment Any tips on getting hired as a software project manager straight out of college?
The answer could just be that "you need to spend some time on the shop-floor" before you work your way up. If you're good, you should bubble real quick because there will be proof (as opposed to 'trust me and my creds')
May
24
comment Are the “practical” chapters at the end of the Siebel's PCL book supposed to be skipped during the first pass?
I already found bits of Ruby and C#'s LINQ halway through the book. Lisp was truly ahead of its time :)