It's Friday afternoon.
Your tasks for the sprint are complete, except for one.
You've finally convinced your PM that a little free time to look i...
For further actions, you may consider blocking this person and/or reporting abuse
I wrote an acceptance test with Codeception for AngularJs project for two months. After two months they wanted me to join backend team because frontend project is always evolving and tests must always be updated. Today I'm helping frontend team to build better frontend project, lol :)
But writing these tests added lots of knowledge to me.
Hi Kevin,
Great article, I really enjoyed reading it.
Just a quick question:
You wrote: "What if you spend all this time setting up your tests, but in the end nothing really comes of it?" and "It takes a lot of work to get a good automated test suite built out. It's not something you can do in the course of an afternoon. "
I agree that it takes time to build a good test suite. My question is, how much time do you consider as too much time spent on setting up the tests?
At what point will you stop the process because it takes too much time?
Thanks!
That's a great question and I think it really depends on what value you can get out of the tests. It may be worth it to spend a week or two getting a test environment set up if you're on a team of 10 and really need the automation. On the other hand, if it's just you and you're working on a project with a small budget, you probably need that time for other things. I think just being honest with what you can afford time-wise is best.
Thanks a lot! I couldn't agree more :)
Which framework do you use to write your tests?
I use WebdriverIO for UI tests. I wrote a post about it here:
dev.to/klamping/how-webdriverio-ma...
Great, thanks :)
For a lot of reasons, mainly because it's the hardest part to test, it has the highest development velocity so it has the lowest Return of Investment result. I mostly refer on "how the UI looks", not the behavior. I'm all for testing the components logic and states, data flows and models, but not the actual UI too, not for fast moving products at least.
Though I like that a lot of ppl are working on simpler ways to test UIs
youtu.be/p_4vA3mt8VE
I would caution UI testing. This can be the first place people reach for after unit testing. Look to test integration before the UI.
I'm still trying out this strategy but the framework we are putting together will isolate the UI from the backend with Wiremock. This will give us validation of the communication from UI to the backend and how the UI behaves to respons. Not sure what web socket mocking looks like.
There are so many benefits to writing UI tests, even if you have a suite of high quality unit tests
UI tests tend to get easier to write over time. There tends to be more code reuse when there is consistent look and feel across your application.
Your testing the absolute outermost layer of your architecture, all the code is being reached, there is no logic being overlooked
The same UI test can be run in so many different ways that can be useful for checking system quality
a. Run the same test on different browsers
b. Run the same test in a Load Test
c. Run the same test with various Mock internet speed, quirks mode, etc.
When tests fail, screenshots can show the impact the error has to the user experience, and help prioritize the severity of the bug.
Yep, UI tests have a lot of power to them! I'm a big fan and these are all great benefits that you don't find with many other testing methods out there!
Your focus gragh is the critical first step. I suggested a pipeline with no tests to start and got laughed at. We actually have similar but different web apps and the response was like, why can't we work on both at the same time... Because each test raises the bar for everyone to use the tests (the system didn't support selecting tests)
Codecept is the best way to write of UI tests, Though setting up the environment was little bit hefty for me. As I was new for the webdriver.