Should I go with TDD, when the deadline is tight?

If it is crazy urgent then I’d ship a just working prototype. It’d have some basic tests that’d save me some time and prevent me from doing manual labour. I’d pour more time and mind towards making the project readily good enough. Once it ships, I will keep adding more tests and turn towards TDD.

Take ideas but don’t base your actions on this thread. Also, without the scope of project and time left there cannot be a definitive guide about what to do.

If it is a very simple project then go for TDD.

I think you will get different answers from different people at the end of the day you have to do what’s right for you. However perhaps answering this question might help:

• Is the project expected to grow fairly large? Is adding new features and maintainability going to be important? If so, I think that’s a good case for writing tests.

If the project is small, or once created unlikely to change much and you need to get it done asap, then maybe testing isn’t quite as important..

Another factor is how proficient you are with Elixir. When I first start with technology I never start with tests, since figuring out how to test things takes twice the time it takes to write the code, which can on it’s own be quite time consuming if you’re just starting out with a new language/framework/etc.

I’d advise to take a step back and figure out how much testing you need to make yourself comfortable with giving the product to the customers. Maybe manual testing is enough, maybe you need a solid coverage of one specific part, maybe you can’t compromise on the quality, maybe the quality is not important (prototype/MVP).

Yeah sir, it will gonna be a bigger one. Also once start it will be hard to redo.
But also we have lesser time, that’s why I raised a question

See BDD / TDD criticized (whole thread, not only the pasted text below )

“Each of us needs to assess how best to spend our time in order to maximize our results, 
both in quantity and quality. If people think that spending fifty percent of their time writing 
tests maximizes their results—okay for them. I’m sure that’s not true for me—I’d rather 
spend that time thinking about my problem. I’m certain that, for me, this produces better solutions,
with fewer defects, than any other use of my time. A bad design with a complete test suite is still 
a bad design.” (http://www.codequarterly.com/2011/rich-hickey/)

… and nobody is concerned about the implications of this statement?

Reads to me like “no time for any testing or thinking about design (much less refactoring)”. Forget about the TDD discussion …

Ultimately an effective approach to automated testing is needed, otherwise:

• You are wasting time with manual testing which occurs too infrequently, or
• You aren’t doing any testing at all

highly philosophical question, so no right answer..

tests can be viewed as a design smell:

I would say getting the contexts and proper seperation/decoupling right or as to close to right is more important than complete tdd coverage:
check this video for intro to context mapping:

short answer is test your contexts interfaces.

of course certains things might need tests, like complex logic/queries, and especially things dealing with time (dst, timezones is great fun)..

honestly most of my functions are so small and simple that I feel like I’m testing ecto and not my code if I put in coverage.

you do also have to watch for DRY vs wrong abstraction.. eg. don’t share one big ecto changeset for all functions, but maybe have the “correct amount” of different changesets. (better to violate DRY than do a wrong abstraction)

some might say having many tests, will hinder future changes and agility..

–

my gist is to focus on contexts, and the interface/surfaces to the different contexts should be small and be tested, but all that goes on inside a context doesn’t need tests(with the exception for complex logic/queries where you need to “prove” that they work in a certain way eg timezone stuff, funky joins etc)..

Yeah sir, just wanted to know how bad it could be if I don’t follow TDD approach for bigger projects.
Thanks

Thanks for the gist sir, I got your points.

This.

I have a bit of a reputation in some circles (probably well-deserved ) for being a testing zealot from years back. These days I take a more moderate stance.

I believe in testing, but I’ve seen it both help and harm a project depending on how you wield the knife. Every test you leave in your suite is a promise to honor the interface (or ignore complaints from your automation system, which is a whole 'nother danger) so use them judiciously. Sometimes today I write tests as a harness for development then remove 50-80% of them when I’m done because they don’t add nearly enough value for the fixed point they represent.

Well designed context boundaries are a sweet spot for your test suite—these are the interfaces the rest of your system should be using, and they are supposed to be relatively fixed. That allows you to refactor ruthlessly within the boundary while trusting that your client code elsewhere will still work. If you only write a few tests, start here. They’ll save you time and headaches down the road for a minimal cost.