Giter Club home page Giter Club logo

iamvery-elixir's Introduction

Iamvery Elixir

Build Status Hex.pm

A set of Elixir utilities for myself and others. Using this Hex package as a test bed for ideas that may be eventually spun off as separate projects or open source contributions.

Installation

If available in Hex, the package can be installed by adding iamvery to your list of dependencies in mix.exs:

def deps do
  [
    {:iamvery, "~> 0.11.0", only: :test}
  ]
end

Documentation can be generated with ExDoc and published on HexDocs. Once published, the docs can be found at https://hexdocs.pm/iamvery.

Phoenix LiveView Test Helpers

Moved to https://github.com/iamvery/skipper.

Copyright and License

Copyright (c) 2022, Jay Hayes.

Source code is licensed under the MIT License.

iamvery-elixir's People

Contributors

iamvery avatar

Stargazers

Nicholas Moen avatar Andrew Haust avatar Jace avatar Stephen Lewis avatar Joe Martinez avatar Mayel de Borniol avatar arkadiy kraportov avatar Sergio avatar Matthew Boehlig avatar Daniel Berkompas avatar Vicente Merlo avatar Nathan Long avatar Jason Johnson avatar avatar Mario Olivio Flores avatar Roman Heinrich avatar marcos ferreira avatar Justin Smestad avatar

Watchers

avatar

Forkers

tiberiuc capitalist

iamvery-elixir's Issues

🐛 Asserting visibility on page after asserting element fails

Problem

Assuming a page like:

<html>
  <body>
    <h1>Hello</h1>
    <p>Greetings from the internet.</p>
  </body>
</html>

A test like this fails in an unexpected way:

start(conn, "/")                    # 1
|> assert_visible("Hello")          # 2
|> assert_visible("p", "Greetings") # 3
|> assert_visible("Hello")          # 4
Assertion with =~ failed
     code:  assert html =~ expected_html
     left:  "<p>Greetings from the internet.</p>"
     right: "Hello"
     stacktrace:
       line # 4

Potential Solution

I would expect a test like above to pass, because I expect each assertion to be made in the context of the full, rendered page. However, the current design on the lib returns the rendered element when targeted...

Licensing?

Hi there 👋

Via the Fediverse I bumped into your nice article on LiveView Testing and the helper functions in this project. Would you consider adding a license so that others can use the snippet directly?

🤔 Submitting a form that does not redirect

Problem

Right now the submit_form function assumes that the response is a redirect. This may not be the case.

How should we handle form submissions that do not redirect?

(Potential) Solution(s)

One option would be to check the response and behave accordingly.

def submit_form({conn, {:ok, view, _html}}, selector, attributes) do
  result = view |> form(selector, attributes) |> render_submit()

  case result do
    {:error, _} -> {conn, follow_redirect(html, conn)}
    _ -> {conn, {:ok, view, result}}
  end
end

Another option would be to remove the assumption and require an explicit "follow" from the caller. I tend to not prefer this option, because the whole purpose of this lib is to minimize required knowledge of underlying live-view-isms.

Consider: Extracting Phoenix LiveView helper functions to its own project

I've continued to find these helpers tremendously helpful in writing LiveView tests that focus on the system behavior rather than LiveView details. It brings me close to the point where I feel it makes sense to pull out a dedicated library. My hunch is that any users of this library would appreciate it leave its obscure corner in my personal utility belt.

Shortcut for open_browser/1

Problem

Using open_browser(view) is nice for debugging, but the pattern here makes it a little tricky, e.g.

start(conn, path)
|> tap(fn {_, {:ok, view, _}} -> open_browser(view) end)
|> ...

(Potential) Solution

Add a new shortcut function like:

def check_in_browser({_conn, {:ok, view, _html}}) do
  open_browser(view)
end

To be used like:

start(conn, path)
|> assert_visible("Something")
|> check_in_browser()
|> assert_visible("Something else")

Is assert_html too prescriptive?

Problem

Currently the implementation of assert_html implies a match of the HTML doc using =~. This may be surprising to some as the name "assert" doesn't necessarily imply any type of assertion.

(Potential) Solution

A couple come to mind.

Rename the function

We could rename the function to match_html which hints a little harder at how the value is compared.

Provide an alternative interface

We could have assert_html provide a way of allowing the caller to define the entire assertion. This may be possible with an anonymous function or as a macro. Here's an example of the former:

|> assert_html(& &1 =~ "Thing created successfully!")

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.