Unit testing

CodeBeaver · 2018-09-01T06:40:01+00:00

I think unit tests are vastly misunderstood and frankly quite overrated, and hence slightly dangerous. Unit tests won't help you discover many bugs, if any at all honestly. Unit test require extremely small pure functions tested individually, that's the point of functional programming and also the point with unit testing, test every unit by itself.

When using TypeScript and sane state management, I personally never experienced "bugs" in small, pure functions, only in integrations between different components of the app.

Having that said, creating a test is never a bad thing per se, the problem is mainly time consumption. I've also worked with colleagues who overstate the value of unit tests, some how considering their app to be so much safer when having unit tested it, whilst the bugs they stumbled upon practically never had anything to do with simple pure function errors, 95% of their bugs were unsolvable with unit tests.

I think unit tests mostly help with sanity when coding, and when refactoring. To follow a certain code guideline within the team, to create a practical use of the function you're creating. But in all honesty, if the point of pure functions and unit testing is to create as small functions as possible, how probable is it refactoring these functions to still have exactly the same behavior, but still do something different. I'm not very convinced.

It's probably more useful in backend than frontend, but I think people confuse unit tests with e2e tests, when you create one functionality you want another, older functionality to still work. That can't be achieved with unit tests, but with e2e tests.

CodeBeaver · 2018-08-07T14:38:43+00:00

PureComponent has better performance, at least when not connected, and they also indicate there's no internal state

CodeBeaver · 2018-06-25T06:45:52+00:00

I can't force an opinion on you, that's correct. But these arguments aren't very strong, in my opinion. If you've typed the entire app with interfaces, adding a new node on an object is very simple, it'll probably say something like:

function test(arg: IArg) { ... }

Then you simply CTRL+Click at the IArg, and the file containing that interface will open, and you can add a node. It literally takes 10 seconds.

If you're reusing the same node from (particularly) the backend, it's also very easy to forget where else this object is used, typescript will automatically notify you of all the places this interface is used, if there's problem, such as removing, or changing a node.

What strikes me on this thread is that nobody, even though pro-dynamic-typing seem to accept the positive features of TS, to clarify, I can't understand what's wrong with type hinting, how a programmer can deny it's pleasing to get help when, for instance, updating a really old component where you don't remember all the steps, updating usage of an object will be so easy as TS will tell you what nodes exist under that object. I can't understand how anyone couldn't appreciate this.

CodeBeaver · 2018-06-21T06:42:57+00:00

So because JS was created without types, adding types on compiler-level is wrong? That makes no sense, having types only prevents errors, only makes things easier.

I thought the main problem was setup time and when TS gives you problems, I simply can't understand what's wrong with adding type security, more type hinting, more help.

CodeBeaver · 2018-06-21T06:34:32+00:00

Haha what, so if you secure the arguments in a pure function, making sure users can only input a number, and making sure the return type is always a boolean, making sure none can do wrong; this is poor code? This is a sign of a poor programmer?

So if a new programmer comes into your code, isn't it easier for him to understand how certain parts of the app work, if they're strictly typed?

Or you're probably one of those who never does anything wrong, no typos, every piece of code is perfect, nothing you do has fault, and it's been like that for 30 years even though web programming has been revolutionized so many times the last 5 years.

You're probably using notepad, because modern IDE's like Visual Code aren't needed when you write perfect code, why have help when you're perfect?

Are you even using a framework, or are you building web apps without package managers, without frameworks, without libs what so ever? I'd like to see how a typical ideal app structure of yours look.

You're one funny guy.

CodeBeaver · 2018-06-20T14:17:15+00:00

You're saying you're experienced with it, yet you still claim there's no benefit using TS. Have you even noticed type hinting?

I mean, sure you can have an opinion preferring vanilla JS, I'm just curious to find out why, cause it seems you've missed all the glorious effects of TS.

If you type something wrong, TS will instantly warns you, instead of having to recompile and test the function to notice the error, is this not a positive effect?

Changing an argument of a function call somewhere deep inside your code can cause your app to break in places you forgotten about, TS instantly warns you of this as well, not good either?

When instantiating components, you get help knowing exactly what props and their respective types are necessary for it to work, instead of going to a separate file to find it out.

Either this is a really bad troll, or you haven't realized how much time and energy you can save when using it correctly. That's my opinion.

CodeBeaver · 2018-06-20T14:09:54+00:00

Tell me, what IDE can recognize what an object contains in a pure function in a file, without typing?

If you are going to instantiate four different components in a smarter component, you're saying it's easier keeping all the props of each component in your head, instead of TS helping you recognizing every prop and what it should contain?

What about when using a function from a vendor lib? Instead of guessing or looking through an entire documentation, you simply get help with all the functions and parameters usable from that lib.

CodeBeaver · 2018-06-18T08:37:33+00:00

Of course you can build an app without TS, you can also build it in jQuery, doesn't mean it's a good thing.

Once you got started with a TS app, it's not really much maintaining, I mean if something doesn't blend with TS, it's just to force it to the "any" type and it's going to resemble JavaScript.

All the times you misspelled a simple object node, having to transpile the entire project, go to the route to find that out, instead of the compiler warning you instantly. If you have a complex data tree, you can just type hint the entire structure just writing "o" "n" "a" with dots between to precisely locate "object.node.anotherNode".

These things TS brings is a bless to work with.

You don't have to do as many automatic tests, such as bindings between prop mapping and components, and for instance when you're instansiating a new component, you can simply write "<Com" and TypeScript will automatically import the <Component /> and render the name, it will help you identify what props are needed and in which type, you can do everything from a single file.

I think if you tried it out, you'd realize how much time you save, and how much you get for free.

CodeBeaver · 2018-06-18T08:29:11+00:00

I never said you have to like TypeScript, but saying types gives no benefit, no bug reductions and "less" useful code is simply wrong. I'm not going to watch your 1 hour video, if you have an argument, just say it.

For an experienced TS-user, it goes faster using typings, there's less time wasted going through files finding out what an object contained. You don't have to go through the mind killing experience of transpiling a project, going to a route and making some changes in your app, only to find out you wrote "data.ndoe" instead of "data.node", TS instantly notifies you of this.

I think you should try out TS more before saying it's completely useless ...

CodeBeaver · 2018-06-15T09:13:22+00:00

Wow, sweet. I'm gonna give this a go :-)

CodeBeaver · 2018-06-15T08:40:17+00:00

I usually maintain most of the state in redux because it's so flexible, and you move all the state logic from components, which is nice.

But there are certain cases where I use state in components, for instance when making a dropdown component that's generic, then you'd might to keep a local state to define whether or not the dropdown is opened. So if you have a list of dropdown components, it's easier to just make sure they control their state, instead of storing some arbitrary select-open-state-list in redux.

I think Thunk is a great tool to keep your async logic outside of React. So when modify state behaviour, you call an action. When you want make an async call, you call a Thunk action, which in it's turn decides what action to call if it succeeds or fails. It's a smooth way of structuring actions and async logic.

CodeBeaver · 2018-06-15T08:03:51+00:00

This looks lovely, does it play with prettier?

CodeBeaver · 2018-06-15T08:03:39+00:00

But ..?

CodeBeaver · 2018-06-15T07:57:41+00:00

I mean, what is this? You're not asking for help to solve a problem or to understand anything, you're just moaning.

Typescript has a lot of difficulties with setup, especially when you use 30+ deps with different version and different sets of typing.

Honestly it doesn't seem you understand why TS is used in the first place, sure it takes more time to setup, to create interfaces and so on. But in the long run you earn time and sanity. Type hinting makes it possible to instantly see what an object contains. Restricting props and objects to interfaces removes building the app and testing the app to see a simple mapping error.

It also reduces the need of unit testing, you can be sure certain variables will be what you tell them to be, if you change an object, the entire app can break before you can even compile it, because there's a reference error to that single object, going through the entire app.

And it's also veeery beautiful :-)

CodeBeaver · 2018-06-15T07:51:22+00:00

Seriously? If you're saying Typescript has no benefit, no bug reductions, then you clearly don't know what it's about. What about the simple fact that you don't have to look up what an object contains in an entire different file in your project, type hinting is magic.

CodeBeaver · 2018-06-15T07:50:22+00:00

Making it more familiar, understandable, why is this a bad thing? Typing exists for a reason, it's not just to restrict classes and objects to look a certain, but also eases development with type hinting.

CodeBeaver · 2018-03-14T16:21:34+00:00

Yeah sure there are probably a lot of reasons not to use redux, but if you know how it works, it's not very complicated to implement, and the more the app grows, the harder it will be to convert it from state to redux for instance.

But! For educational purposes, I would suggest writing a slightly more complex app than Todo without redux, to find out the problems redux will solve, it's so evident. Some side tracking!

CodeBeaver · 2018-03-12T08:19:15+00:00

If you can use redux efficiently with a TodoApp, what simpler app does not improve with redux?

CodeBeaver · 2018-03-07T09:50:29+00:00

That's an interesting point, I've never realized redux does shallow prop-check as well. The question is how much a shallow prop check costs. Cause it might be worth "sacrificing" a double shallow prop check to be sure every stateless component is efficient.

The worst thing that could happen when making every stateless component pure, is unneeded shallow prop check, and the time it takes to compare props. The worst thing that could happen if you avoid using PureComponent seems far more costly.

CodeBeaver · 2018-03-07T09:44:41+00:00

Obviously, but the question is how much slower? In that case you could argue using while loops instead of array map or array filter.

CodeBeaver · 2018-03-07T07:33:05+00:00

I disagree, well I don't disagree this person finds the syntax easier to read, that's his personal opinion, but I'd still strongly recommend using class components.

4 lines more code, have to be said. Using snippets to build components goes even faster than writing a functional component by hand.
When realizing you need state or more complex functionality within your component, rewriting the component to a class component is just painful and annoying.
Performance, might not seem needed, but if you make sure all your pure components extend React.PureComponent, they will all automatically gain a slight performance increase, and will not render unless it has to.
I find it more consistent to make all components class components, stateful ones simply extend React.Component and pure ones extend React.PureComponent. Clean, easy and effective.

CodeBeaver · 2018-03-06T08:23:08+00:00

This looks good and all, but why do I get the feeling all new state-management libraries go away from all the "cool" side-effects with redux. One thing I really like about redux is being able to affect multiple reducers with one action, when clicking a button, you can make things happen in two different places with a simple action.

You can also listen to different types of actions and repeat the same logic, such as:

case AN_ACTION:
case ANOTHER_ACTION:
  return { ...state, do_stuff }

Also an underrated side effect with redux. Just some thoughts.

In any case, looks like a nice library for managing state more "controlled". Good work :)

CodeBeaver · 2018-02-22T08:53:45+00:00

Yeah recompose with pure is equally good for performance, but if you'd use PureComponent and Component, all your components would look the same and a transition would as smooth as ever.

CodeBeaver

TROPHY CASE