I've been recently asked this question in an interview and this was my answer:
Pure unit tests and shallow rendering idea
For ReactJS in particular, there are many testing libraries that allow you to do shallow rendering (enzyme for example), that means that if you have a composed component, the test won’t actually render that inner component so you can’t make assertions on that. If you want to cover those internal components you need to write specific tests for each part.
For example:
<div>
<Form>
<Username />
<Email />
</Form>
</div>
With this structure, if you want to write a test for this component, the first div will be rendered but the custom Form component won’t, neither the Username and Email components, they will be mocked. You will have to test them individually, which follows the pure unit testing idea, but you can’t ensure that the components work ok together.
If you follow this pattern, you will soon end up with a set of pure unit tests that are really confusing and hard to follow.
Tests should resemble the way the software is used. Even though is not pure unit tests (technically you can call it integration test), at the end of the day the only thing that matters is that you can ship your app with confidence.
Resources:
Image by Gerd Altmannfrom Pixabay
Oldest comments (119)
My least favorite practice is a function that looks pure but actually has side effects.
I don't think that's considered best practice at all. Lol
But yes, that sucks.
I question anything too religious around small files and tiny methods. Sometimes the better choice is to toss another method in the class so it’s easy to find rather than stash it away elsewhere in the codebase.
git grep
My counter to this is that with any suitably large product, having a logical folder structure that you religiously stick to, regardless of file size/content† , you can reliably find the content that you are looking for. Okay you occasionally deal with a silly file, but its better than having someone recreate something and have inconsistency between what should be functionally identical.
For small/informal project then I understand the convenience, but otherwise i feel it can add to problems long-term, especially when working with big/multiple teams.
† have a single exported const in a file for all I care
Use an ide, preferrably a jetbrains one.
I think modern IDEs are pretty smart to walk you to the file/class which encaosulates the method.
For me the method length limit is imposed by the response to simple question - "What the method accomplishes?". If you are not able to answer without using AND ..this.. AND ..that. AND ... multiple times, then it is time to better encapsulate the logic and maybe change the project's design.
That's the reason why we have two kinds of tests: unit tests for the individual components, and integration test for the whole package. To resemble the way your software is actually going to be used, you should focus and stress on the latter.
The former (unit tests) just ensures that the component doesn't break on its own, its only really helpful in large orgs where multiple teams develop their components separately and the build or devops team then integrates the whole thing.
If you are a solo dev who does both backend and frontend, it'd make sense to combine them, the integration test is the unit test for you, doing it separately will simply be a waste of time.
Yep. I think we're discussing the difference between 'acceptance tests' and 'unit tests' - as Uncle Bob calls them.
I think 'front end' (not meant as a derogatory term!) devs tend not to think about unit testing as being worthwhile. Part of that is probably because there aren't as many layers in the front end 'project' structure as there usually is in the back end. In the back end I hope you'd expect both unit tests and acceptance tests, but if there aren't any complicated functions that need unit testing, maybe the acceptance tests are enough.
80 characters per line is a common one. I feel that this is an old practice from technical limitations that lived on. I do not go overboard with extremely long lines of code, but with widescreen monitors, 80 characters seems a bit limiting.
If I remember correctly that stemmed from the COBOL era where a punch card only had a certain number of characters across plus a blank column (the fourth I think?) for the sorting wheel to put cards in order.
I don't think I've ever adhered to a certain number of characters in C#.
Plus, in the 80s graphic cards the standard text mode was 80 columns X 24 lines.
My coworkers use huddled terminals in an i3 workspace and with Vim, they appreciate having 80 characters per line.
same here, 80 chars are visible in 3 columns at 1080p; and also 1 vim column + browser without triggering the "small screen websites format". By the way, i3 + nVim is perfect
I prefer 120 characters, and stay pretty strict on that limit. 80 chars definitely is not enough, but I do like having a hard limit on line length.
Erm, nobody insists on that anymore so no, not common at all - it's long been revised to 120.
Popular linters and formatters for JavaScript default to 80 characters:
eslint.org/docs/rules/max-len
prettier.io/docs/en/options.html#p...
Like everything else about JavaScript, This limit is regressive at best.
I appreciate code that has an 80 char limit, means I can put two code panes next to each other without having to put the font eyebleedingly small
I think 80 is just for encouraging good practices. Some people tend to ignore soft recommendations like "don't go overboard", but will follow hard limits.
It's not just a technical issue. longer lines are harder for the human mind to parse out. In text, 50-60 characters are ideal. I think more than 80 in code is pushing it. Having said that, I agree that it's not something to be too dogmatic over. We have our linter set to 125 cpl.
I'm pretty fond of 80 characters being the limit.
I have heard of the 50-60 being ideal, but I thought that was more for reading sentences than text in general. I could be wrong though, I haven't looked at the studies on it.
Over 80 characters per line means project is written in some ancient language. For example Java.. or other older strongly typed language where it's occasionally impossible to make code nice & readable 😅
That, or there is some bigger issues in code structure.
It has another use case: showing code on a presentation (you need to increase the base font size) keeps your code formatted and in the screen.
Yeah, multiple screens are common nowadays. Super long line is not encouraged. For easy reading I prefer 120~130.
80 characters per line is horribly outdated, it would make most of my code look ugly especially in a more verbose language like PHP.
120 characters per line is fine, that's much more okay.
Write comments in every function, and at the beginning of every class. Sometimes the projects will go really complicated, then you must roll over again every class you write just to look what it does.
What you need to do is create a structure and a walk through tutorial when things out of hands.
Code comments can be like deodorant for code smells. If you feel like writing a comment to clarify something, first try to change to structure of the code itself to make things more clear. Most of the time, simple (and safe) rename refacterings can be enough. After that try putting boolean expressions in properly named variables. If your happy about the naming you then can extract a method out of it so you can hide some of the implementation so the reader of your code doesn't have to mentally parse every tiny detail to get the big picture.
If you always so this your code will read like a story. Digging deeper you will find technical implementation but at the higher level it should be understandable by first time readers without having to peek at the lower levels. It takes a lot of practice and discipline tough.
;
That code should be as few lines as possible. There's an element of refactoring that is important so that it's efficient, but it should also be understandable.
I believe you shouldn't write code as if you're going to be the one dealing with it, but someone underneath your level of understanding.
“I didn't have time to write a short function, so I wrote a long one instead.” - Mark Twain :)
If anything, best practices are general guidelines to create clean code. I think it really helps working towards them (split unnecessary long functions up, make speaking names, etc.) but not enforce them
For individual projects -- all of them. It's good to know what folks have established as good ideas, but the ideas should be applied as a result of evaluating the costs & benefits for your particular case. i.e thought-driven development.
And honestly, for many projects, cargo cult programming will probably get you through, and it'll save you from having to do too much thinking, but it's far from the most direct route.
Spaces over tabs
Team tab here.
Spaces over tabs for fixed width fonts. Tabs over spaces for proportional fonts. This way the indenting is consistent.
I don't see the advantage of tabs, is just a character that you can't differentiate from another just by looking. To me is like having to A that looks the same but are a different unicode. I like to think that in the future, when we solve all big problems, this will be one of the big wars WWX maybe, just after the big WWIX of Vim/Emacs.
You can render tabs as any width, while spaces are fixed. This is really useful for formats like yaml (which forces you to use space, btw) where it can get very clumsy with small width of white space
I would like that the "r"s of my name looked like flaming swords and the "o"s like eagles, but the main purpose of written language is to visually recognize what is in there and to agree on that. You can't see the difference between a tab and a bunch of spaces, that should be the first priority, everything goes after that, including style; btw, you can use multiple spaces in yaml and in any language I know of, if you are reading code with a single space indentation you should murder the one who wrote it, I think that even a judge would understand. Even 2 spaces are questionable, to me 4 are ideal and 8 like the Linux Kernel guidelines is going too far.
With tabs you can render them as you like ;p even as 3 or 7 spaces :)
I found this article helpful in understanding the difference: dev.to/alexandersandberg/why-we-sh...
The argument exposed there "accessibility by default" is flawed, accessibility needs of few are often opposed for the needs of the many. If you have trouble seeing 4 space indents, almos all editors have vertical lines, different colors, font size, space markers, etc. Is a weak argument for tabs. no 2 different characters should look alike, and unless you want to use tabs for all spacing, to me tabs are out. If I see a blank character I know what it is and can even estimate how many. That's why we use text editors and not word processors in the first place or let all just use MS Word or Libreoffice Write to program.
I didn't care about this argument until I read about the accessibility issues surrounding the use of spaces for those who are visually impaired.
reddit.com/r/javascript/comments/c...
I used to be strongly for tabs over spaces, nowadays I strongly prefer spaces over tabs, yet I am slightly annoyed by the fact that it's now more difficult for me to customize just how wide the indentation is.
Why I now prefer spaces, is that once the indentation is in place, it won't just go haywire on different machines. E.g.:
This kind of a thing would be regularly painful with tabs.
reddit.com/r/javascript/comments/c...
It's quite annoying when people just reply with a link instead of even sharing the gist of it and then the link for additional reference.
Tell this information to people writing PEP-8,
black,gofmtand other such things. It's valuable feedback, but since fighting about formatting is not worth the time I use tools to auto-format everything and they will force the codebases to use spaces.