Skip to content
This repository has been archived by the owner on Feb 24, 2024. It is now read-only.

Proposal: ActionSuite #242

Closed
markbates opened this issue Feb 14, 2017 · 3 comments
Closed

Proposal: ActionSuite #242

markbates opened this issue Feb 14, 2017 · 3 comments
Assignees
Labels
breaking change This feature / fix introduces breaking changes enhancement New feature or request
Milestone

Comments

@markbates
Copy link
Member

markbates commented Feb 14, 2017

Lately I've been finding myself using test suites more and more in my applications. I'm wondering if this is something that we should add to Buffalo. While this proposal talks about ActionSuite that would be used for testing actions, a similar one, ModelSuite, would be created for testing models.

My typical ActionSuite usually looks something like this:

type ActionSuite struct {
	suite.Suite
	*require.Assertions
	DB     *pop.Connection
	Willie *willie.Willie
	app    *buffalo.App
}

func (as *ActionSuite) HTML(u string, args ...interface{}) *willie.Request {
	return as.Willie.Request(u, args...)
}

func (as *ActionSuite) JSON(u string, args ...interface{}) *willie.JSON {
	return as.Willie.JSON(u, args...)
}

func (as *ActionSuite) SetupTest() {
	as.DB.MigrateReset("../migrations")
	as.Assertions = require.New(as.T())
	as.Willie = willie.New(as.app)
}

func (as *ActionSuite) TearDownTest() {
}

Then in my actions/actions_test.go file I would create a Test function that looks something like this:

func TestActionSuite(t *testing.T) {
	as := buffalo.NewActionSuite(App())
	c, err := pop.Connect("test")
	if err != nil {
		t.Fatal(err)
	}
	as.DB = c
	suite.Run(t, as)
}

Which means my tests now look like this:

func (as *ActionSuite) Test_SomeAction() {
        as.DB.Create(&SomeModel{})

	res := as.HTML("/some/url").Get()

	as.Equal(200, res.Code)
	body := res.Body.String()
        as.Contains(body, "some text")
 }

I find this really nice and clean, and means I can add nice setup/teardown to my tests.

So the question is should this be included in Buffalo or should I release this as a separate package that people can use if they desire?


Included in Buffalo Pros/Cons:

Pros

  • It's there and ready to use for everyone
  • Generators can be setup to use it
  • testify is already being depended on by Buffalo, so there's no extra dependency

Cons

  • Not everyone would want to use it
  • People would have to delete generated code if they don't want to use it, or, generators would have to have a flag to turn on/off usage

Separate Package Pros/Cons:

Pros

  • People who want to use it can just import the package and use it.

Cons

  • Generators can't use it with a flag that turns it on
  • People might not be aware of it, so it's usage would probably be lower
  • Keeping it in sync with the Buffalo project

I'm looking for thoughts/opinions on this.

@markbates
Copy link
Member Author

To add some meat on this proposal, here is a package that implements this proposal:

https://github.com/gobuffalo/suite

Right now it can be used standalone, but if people like it we can add it to the main repo.

@paganotoni
Copy link
Member

I like this idea, i understand the trade-offs buffalo would be making by introducing this but IMHO the wins are larger and will make testing easier/faster while increasing productivity.

Thanks @markbates for sharing this proposal, hoping to see this getting into buffalo soon and willing to help as possible.

@vedhavyas
Copy link

Even, I love the idea of including it in Buffalo. It makes it more convenient when you look at Buffalo framework as a whole.

We could always give a flag to not generate the code with default as True.

markbates added a commit that referenced this issue Mar 19, 2017
@markbates markbates added breaking change This feature / fix introduces breaking changes enhancement New feature or request and removed Proposal labels Mar 19, 2017
@markbates markbates self-assigned this Mar 19, 2017
@markbates markbates added this to the 0.8.0 milestone Mar 19, 2017
markbates added a commit that referenced this issue Mar 20, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
breaking change This feature / fix introduces breaking changes enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants