Where programmers share ideas and help each other grow. All developers are welcome to submit stories, tutorials, questions, or anything worth discussing. The front page is curated by the folks behind @ThePracticalDev.
Have fun and don't be afraid to contribute, everyone's perspective is valuable! ✌️
I've always worked on projects where the tests were in a separate parallel tree from the code. This makes it easy to run the tests but figuring out where a test for a particular method lives can be a challenge. We always try to make the two trees as similar as possible, but they always diverge and that makes working on legacy code difficult.
I've never actually put code and tests in the same file except for code katas and demos. One one hand, it feels like it might make files too big. On the other hand, maybe it would also encourage breaking up the code into more reasonable module sizes. I probably wouldn't know how it felt until I tried it on something large.
In the end, I'm all for getting the tests closer to the code rather than in a separate parallel tree. Most of the test frameworks out there seem to encourage a separate tree, so I find myself still working in that way.
Ask 5 Ws of Dev Experience:
1. Who are your tools? (tmux/vim? emacs? atom? xsort? concept mapper? toolkits? grunt/gulp? browser plugins? package managers? cli tools? interesting one-liners?)
2. What's your best/daily workflow? (What do you typically feature-branch for?)
3. When are your best times for achieving flow? (8-12? 4-11? nightowl?)
4. Where are your best places to work? (This is more about lighting and social conditions matching.)
5. Why do you not like X (some known existing tech of the company that involves tech debt of some kind or that the dev must conform to)?