testing-concept-fast-full-application-tests

In introducing.us, I had JavaScript tests that tested view model logic across an entire funnel, since user input and HTTP connections were both seen as external actions.

it "do the full NUX funnel", ->
  expect(currentStep().constructor).toEqual(MyInfoStep)
  currentStep().onAdapterTellsThatNameUpdatedTo("George")
  currentStep().onAdapterTellsThatRoleUpdatedTo("groom")
  currentStep().onAdapterTellsThatNextButtonClicked()

  expect(currentStep().constructor).toEqual(FianceInfoStep)
  expect(currentStep()._pageDataObject.getValueFor("page_found_photos")).toBe(null)
  currentStep().onAdapterTellsThatNameUpdatedTo("Ma")
  waits 5
  runs ->
    currentStep().onAdapterTellsThatSearchResultAtIndexWasChosen(0)
    expect(currentStep().getName()).toBe "Mary Tubbins"
    expect(currentStep().getFacebookId()).toBe 713753,
    waits 5
    runs ->
      expect(currentStep()._pageDataObject.getValueFor("page_found_photos").length).toBe(2)
      currentStep().onAdapterTellsThatRoleUpdatedTo("bride")
      currentStep().onAdapterTellsThatNextButtonClicked()

      expect(currentStep().constructor).toEqual(PageUrlStep)
      currentStep().onAdapterTellsThatPageUrlUpdatedTo("georgemary")
      waits 5
      runs ->
        expect(currentStep().validationErrors().length).toBe(1)
        expect(currentStep().validationErrors()[0]).toBe("You can do better, pick another URL")
        currentStep().onAdapterTellsThatPageUrlUpdatedTo("george+mary2012")
        waits 5
        runs ->
          expect(currentStep()._pageDataObject.getValueFor("display_name")).toBe "George & Mary"
          expect(currentStep().getPageUrl()).toBe("georgemary2012")
          expect(currentStep().validationErrors().length).toBe(0)
          currentStep().onAdapterTellsThatNextButtonClicked()
          waits 20
          runs ->
            expect(stepManager()._adapters[0].testInfoPageUrlThatWeWentTo).toBe("georgemary2012")

podcast-rr-196-testing-clojure-in-ruby#avdi-state-space

at 52:30, Avdi asks a question:

"by testing the application from the frontend, your inputs are actions. Your inputs are high level human actions. And it's almost like the algorithm that you're testing is the application moving over the state space, which is cool."

[snip]

"does this change your perception of your application architecture at all? Or do you think differently about architecting your application because you're thinking about actions, human actions, as these composable parts of input?"

 

Avdi's comment sounds very similar to the concept I have in mind where user input, view lifecycle, external events like push notification opens, data from the database, network data, are all inputs into the application-algorithm.


testing-concept-fast-full-application-tests#independent-of-redux1Redux's reducers' results are potentially deeply nested structures. Could the results of

talk-hot-reloading-with-time-travel#root-reducer

At 17:40 unlike event emitters, pure functions are very easy to compose. This is the purpose of a root reducer.

 

basically be the full application state? Do they actually have to be tied to redux in any real way, or could you reason about events applied to application state independent of a framework (like Redux). Seems like you could. testing-concept-fast-full-application-tests#independent-of-redux1

Referring Pages

handling-the-data-flow

People

person-avdi-grimm