Jump to content


Photo

General JavaScript


  • Please log in to reply
371 replies to this topic

#361 rbrtsmith

rbrtsmith

    Web Guru

  • Privileged
  • PipPipPipPipPip
  • 3,715 posts
  • Gender:Male
  • Location:Manchester, UK
  • Experience:Nothing
  • Area of Expertise:Web Developer

Posted 16 March 2017 - 10:01 AM

I've been using Jest for a while now and I have to say I'm really enjoying it. I find it's much faster than Mocha/Chai and it's extendable too which means I can create my own methods for validating data.

 

Glad you like it.  I hated it when we first used it in work about 10 months ago, it did lots of horrible things like autoMocking modules, but that's been taken out and lots of good work has been done on it.  We decided to try it again in work and will be sticking with it for the foreseeable future now.

It was initially aimed at React consumers but it's useful outside of that.  We wrap out Nightmare.js E2E tests in Jest blocks & assertions and use it on the server side too (For Node / Express projects)



#362 Lyndsey

Lyndsey

    Web Guru

  • Moderators
  • PipPipPipPipPip
  • 1,062 posts
  • Gender:Female
  • Location:South Wales
  • Experience:Intermediate
  • Area of Expertise:Web Developer

Posted 16 March 2017 - 11:07 AM

 

Glad you like it.  I hated it when we first used it in work about 10 months ago, it did lots of horrible things like autoMocking modules, but that's been taken out and lots of good work has been done on it.  We decided to try it again in work and will be sticking with it for the foreseeable future now.

It was initially aimed at React consumers but it's useful outside of that.  We wrap out Nightmare.js E2E tests in Jest blocks & assertions and use it on the server side too (For Node / Express projects)

 

The documentation is easy to follow, which helps.

 

Also, I've been finding the test-first approach OK so far. Writing the test before the implementation means I'm writing less code and it's so much nicer to read. Although, I'm not sure if this is more related to functional programming as I've recently been learning a lot about it and have been trying to implement the methodologies as much as possible.

 

JavaScript is so awesome right now, though!



#363 Jack

Jack

    NaN

  • Moderators
  • PipPipPipPipPip
  • 2,968 posts
  • Gender:Male
  • Location:Jersey Channel Islands
  • Experience:Advanced
  • Area of Expertise:Web Designer

Posted 16 March 2017 - 01:03 PM

 

Looks cool that, thanks for sharing!

 

Have you tried wallaby btw? I love it.

 

Nah, I don't write enough tests in my day-to-day job to warrant it. I was watching the Jest talk at React Conf a couple days ago, both watch mode and snapshots look really cool. Watch mode seems a lot like Wallaby in how it works.



#364 citypaul

citypaul

    Privileged

  • Privileged
  • PipPipPipPip
  • 763 posts
  • Gender:Male
  • Location:Manchester
  • Experience:Nothing
  • Area of Expertise:Web Developer

Posted 16 March 2017 - 09:02 PM

 

Nah, I don't write enough tests in my day-to-day job to warrant it. I was watching the Jest talk at React Conf a couple days ago, both watch mode and snapshots look really cool. Watch mode seems a lot like Wallaby in how it works.

Having played briefly with snapshots, I have to say I'm a bit "meh" about them tbh. They're certainly not something you can really incorporate into TDD, and they don't test for behavioural correctness. I'm not sure I really understand where they fit in in general. I did try Jest myself for a bit but just couldn't see any advantage to it, so went back to mocha/chai for now. 

 

The snapshot stuff may have some use in a limited context, but I'd be worried that developers would focus on those too much, which would encourage them to not write their tests first, which leads to code that isn't covered properly.

 

Dunno if I've mentioned on here, but we're now at the stage where we've given up manual testing almost completely, yet we still release stuff to live usually multiple times per day. We've got such confidence in our tests now that we just (usually) go straight to live if they pass. Not something you'll ever get without writing code test first, or with an over reliance on snapshot testing.

 

I kinda get the feeling the feature was developed because people want to be a bit lazy and can't be bothered writing tests properly. That's the impression I get.

 

Not seen watch mode for Jest though - that may be more interesting if it works in a similar way to Wallaby. The Wallaby guy owes me a few beers I thin, because we've got nearly 10 devs setup on it now in work, and he gets about £200 per license. I kept showing people the tool and eventually people got jealous enough that they put pressure on the powers that be to buy licences for people.

 

Mind me asking why you're not writing tests in your day to day job? Are you not convinced of the value they give you?



#365 citypaul

citypaul

    Privileged

  • Privileged
  • PipPipPipPip
  • 763 posts
  • Gender:Male
  • Location:Manchester
  • Experience:Nothing
  • Area of Expertise:Web Developer

Posted 16 March 2017 - 09:04 PM

 

Glad you like it.  I hated it when we first used it in work about 10 months ago, it did lots of horrible things like autoMocking modules, but that's been taken out and lots of good work has been done on it.  We decided to try it again in work and will be sticking with it for the foreseeable future now.

It was initially aimed at React consumers but it's useful outside of that.  We wrap out Nightmare.js E2E tests in Jest blocks & assertions and use it on the server side too (For Node / Express projects)

 

Horses for courses and all that I think. I don't think there's any real advantage to using Jest from what I can see. It seems to work well enough, but Mocha/Chai works perfectly well for me and having played with Jest a little bit now I just saw no reason at all to change.


Edited by citypaul, 16 March 2017 - 09:05 PM.


#366 citypaul

citypaul

    Privileged

  • Privileged
  • PipPipPipPip
  • 763 posts
  • Gender:Male
  • Location:Manchester
  • Experience:Nothing
  • Area of Expertise:Web Developer

Posted 16 March 2017 - 09:24 PM

Just to be clear again - I've no issue with Jest (asides from the old version you mentioned that did automocking, which is awful and definitely a big "no"), but I just see nothing about it that's compelling enough to make me want to move from what I generally use. I'd have no issue if I were working on someone else's code and they were using Jest, although I'd be wary of front end tests that were just testing using Snapshot tests. I'd probably go so far as to argue against snapshot testing in general, although there may be some contexts in which case it's useful.

 

I noted on Brian Holt's React Frontendmasters course that he basically says he doesn't like testing, which probably explains why he advocates the snapshot approach. I reckon it's also why he advocates the shallow rendering approach in most places - both of which are bad practices (that in general are assumed to be "best practices") in my opinion. The way I test is different to how a lot of people in the industry do it, but it produces much better results, and the reason I say that with a certain amount of confidence is because we're so happy with our tests now that as I said above, we've all but abandoned manual testing altogether. 

 

We have a new principal tester (promoted internally) in Sport, and he gave a talk today based on this: https://www.thoughtw...ts/blog/qa-dead where we basically argued that QA should now be focusing on ensuring our automated tests meet the quality standard, instead of wasting their time doing manual testing. 

 

I know this isn't typical in the industry, and I'm convinced it's largely because people do things like over mocking (which in a React world means over reliance on shallow rendering, as well as using your typical mocks in the standard way).

 

It really comes down to writing tests that are designed from the outset to handle change, and that usually means reducing the mocks you use, and preferring a full render over a shallow render.

 

Unfortunately it's never black and white, and shallow rendering is definitely useful too, but I'd recommend doing a full render as standard and using shallow rendering only where you need it - the inverse of what a lot of people recommend. I bet those people expect a certain level of manual testing though ;-)

 

One day I really will write about this stuff. Probably. Definitely maybe ;-)

 

*Edit: And to be clear, for people using test frameworks for the first time, Jest may be a nice option. I'm glad you're happy with it Lyndsay... It's just that for me personally, I don't see a reason to move if that makes sense? 

 

I'd highly recommend continuing with the test first approach for a significant amount of time to see how it really pans out for you over time. When you come back to code you wrote 4-5 months ago and don't fear making changes, you'll really start to appreciate it...


Edited by citypaul, 16 March 2017 - 09:26 PM.


#367 Jack

Jack

    NaN

  • Moderators
  • PipPipPipPipPip
  • 2,968 posts
  • Gender:Male
  • Location:Jersey Channel Islands
  • Experience:Advanced
  • Area of Expertise:Web Designer

Posted 17 March 2017 - 09:18 AM

Horses for courses and all that I think. I don't think there's any real advantage to using Jest from what I can see. It seems to work well enough, but Mocha/Chai works perfectly well for me and having played with Jest a little bit now I just saw no reason at all to change.

 

 
This is the video I watched. I like the idea of using a single framework to handle everything from standard assertions to UI. I'd be interested to find out if you consider anything on the video to be bad practice, or perhaps there's another way the example could be tested.
 
---
 
On a side note, the videos from React Conf are up. Some of the highlights for me were Tom Occhino - React Fiber, Robert Zhu - Realtime React Apps with GraphQL, Michael Jackson & Ryan Florence - Learn Once, Route Anywhere and Guillermo Rauch - Next.js.



#368 rbrtsmith

rbrtsmith

    Web Guru

  • Privileged
  • PipPipPipPipPip
  • 3,715 posts
  • Gender:Male
  • Location:Manchester, UK
  • Experience:Nothing
  • Area of Expertise:Web Developer

Posted 17 March 2017 - 11:29 AM


The main plus for Jest is that it requires no setup, it just works out of the box.  I know you don't see a huge benefit in coverage reporting, but with Jest it's literally just an option that you pass into the the call.  There's no messing around setting up Istanbul etc.  For those times that you do need to Mock you don't have to pull in Sinon or some other library, again it's all just baked into Jest and the documentation is very well thought out.

While I don't think you'd gain much yourself by switching to Jest, for those just starting out it's a nice place to start without having to worry about confusing setup and config.

 

Snapshots are just useful to see if you have made breaking changes to a presentational component (UI), on paper that seems useful but to be honest we're not using them and aren't really missing the feature.  It's quite immature and I've heard reports of some bugs coming out.  I think it's something worth keeping our eyes on as things progress.

Correct me if I am wrong but shallow rendering is going to allow your tests to run faster and means that your test is only concerned with that one component whereas Mount feels more like an integration test.  as it renders that component and all of it's descendants
We're calling them (mount rendered tests) Duck tests in our project at work as it kind of mirrors the Redux Ducks structure so we will test a Duck.

 

https://github.com/e...s-modular-redux for those interested / curious to know what a Redux Duck is :)

We have found both shallow and mount tests to be both useful, I think it's down to testing the right things, we tend to test the logic in a component and not bother testing that a static header is present in the JSX for example.  That's where snapshots would come in.  

We could have a component <Users /> which renders a list of users ordered by surname.

import React, { PropTypes as T } from 'react'
import sortBy from 'utils/sortby'
import User from './User'

const Users = ({ users = [] }) => {
  const sortedUsers = sortBy(users, 'surname')
  return (
    <div className="c-users-card">
      <h2 className="c-title">Users list</h2>
      <p>Some description of our users</p>
      <ul className="c-users-list">
        {sortedUsers.map(u => <User key={u.id} user={u} />}
      </ul>
    </div>
  )
}

Users.propTypes = {
  users: T.arrayOf(T.shape({})
}

export default Users

We would write a test to ensure that the component renders the correct number of User components and sorts them by their last name.  For this test Enzyme's Shallow rendering utility is sufficient.

import React from 'react'
import { shallow } from 'enzyme'

import Users from '../Users' 
import User from '../User'

const users = [
  {
    id: 'user-1',
    firstName: 'John',
    surName: 'Smith',
    age: 25,
  }, {
    id: 'user-2',
    firstName: 'Fred',
    surName: 'Flintstone',
    age: 98,
  }, {
    id: 'user-3',
    firstName: 'Jack',
    surName: 'Sparrow',
    age: 40,
  }
]

describe('<Users />', () => {
  it('renders a list of users ordered by surname', () => {
    const $ = shallow(<Users {...{ users }} />
    const findUserIdByIndex = index => $.find(Users).at(index).prop('key')

    expect($.find(Users).length).toBe(3)
    expect(findUserIdByIndex(0)).toEqual('user-2')
    expect(findUserIdByIndex(1)).toEqual('user-1')
    expect(findUserIdByIndex(2)).toEqual('user-3')
  })
}) 

So we are just testing the logic of the component, we don't test that the heading and paragraph component are visible or the classnames.  We would test classnames that are dependant on logic of course.  Snapshots would come in to ensure that any changes to this component get flagged up.  Again I'm not sure how useful that actually is?

The sortBy utility would be independently tested itself.


Edited by rbrtsmith, 17 March 2017 - 03:57 PM.


#369 Jack

Jack

    NaN

  • Moderators
  • PipPipPipPipPip
  • 2,968 posts
  • Gender:Male
  • Location:Jersey Channel Islands
  • Experience:Advanced
  • Area of Expertise:Web Designer

Posted 20 March 2017 - 09:47 AM

Interesting article on functional setState


Edited by Jack, 20 March 2017 - 09:48 AM.


#370 rbrtsmith

rbrtsmith

    Web Guru

  • Privileged
  • PipPipPipPipPip
  • 3,715 posts
  • Gender:Male
  • Location:Manchester, UK
  • Experience:Nothing
  • Area of Expertise:Web Developer

Posted 20 March 2017 - 11:52 AM

 

It should always have been functional rather than being able to accept an object or a function, passing an object like the article describes can be error prone.  That said I'm using Redux for all the apps I am building right now so don't have much use for setState.

It also has the added bonus that I can avoid using classes for my components as long as they don't have lifecycles events.

 

Once you're familiar with Redux it doesn't add much complexity or boilerplate to your app, so I use it even for small ones unless it is really trivial.  It also ties nicely into routing etc.  And as your app grows which it almost always does you don't have to mess around refactoring components having to move state higher up the tree and then having to pass lots of props down to components that only their descendants care about.  Redux actually avoids a lot of boilerplate and components only receive the props they actually care about.


Edited by rbrtsmith, 20 March 2017 - 11:55 AM.


#371 Jack

Jack

    NaN

  • Moderators
  • PipPipPipPipPip
  • 2,968 posts
  • Gender:Male
  • Location:Jersey Channel Islands
  • Experience:Advanced
  • Area of Expertise:Web Designer

Posted 24 March 2017 - 01:56 PM

Just a quick one. if you go to next.frontendmasters.com you can use the new video player. It's much better, especially how it tracks your completed steps.



#372 rbrtsmith

rbrtsmith

    Web Guru

  • Privileged
  • PipPipPipPipPip
  • 3,715 posts
  • Gender:Male
  • Location:Manchester, UK
  • Experience:Nothing
  • Area of Expertise:Web Developer

Posted 24 March 2017 - 03:41 PM

An interesting repo here covering a full stack development app in Javascript: Backend, frontend, infrastructure & deployment.  It gives a good overview of the whole stack.

While doesn't go into great deal into any of the concepts I think it's a solid introduction to the most modern tools used in JS application development.

https://github.com/v...ck-from-scratch

 

Only part that seems to be missing is a database layer, but it looks as though the Author is planning to add this soon.


Edited by rbrtsmith, 24 March 2017 - 03:42 PM.





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users